This needs some clarification, since there could be other reasons why a tx is not ready for inclusion, other than nonce gaps, for example not enough balance or max fee below current base fee.
So either queued is only related to nonce gaps, and in that case the description should say that other reasons are excluded, or "(nonce gaps)" should be removed.

We have to either restrict the definition OR remove "(nonce gaps)" to be more general?

the direction could be driven by what existing implementations do right now, do they keep only nonce gapped txs in the queued pool, or not?

Since Besu does not yet have this API, we'd like to know what to report as part of the queued pool.

I understand it is convenient to return all the txs with a single call, but that does not scale well with large pools, and could hit some of the RPC response size limits, so it would be nice to have some kind of agreed limit on how many are returned by this call.

The same applies also to other calls, only txpool_status has a bounded response size, so a general approach to filtering and/or pagination could be evaluated.

I guess the question is: Are we documenting the feature that already exists and how clients treat the method today, or are we trying to standardize something new and push the clients to change? Because this is how the method works, in basically all the clients today.

https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool#txpool-content

https://reth.rs/jsonrpc/txpool/#txpool_content

https://docs.nethermind.io/interacting/json-rpc-ns/txpool/#txpool_content

https://docs.erigon.tech/interacting-with-erigon/interacting-with-erigon/txpool#txpool_content

Both things are valuable, and could be part of an iteration, where starting from the de facto standard, API are evolved to match current use cases.

Sure but I don't know if pagination is even an option, the mempool changes constantly, you wouldn't be able to split transactions into pages AND track the pages between calls.

In theory the mempool is already bound by a max size that is configurable on the nodes. You'r right in that it returns potentially a very large responses and is annoying to support at the RPC provider level, and many don't, they simply turn it off / block it.

txpool_content is ripe for abuse from MEV bots and searchers against the pulbic mempool, but it can also be a useful debugging tool to pull all the txs out of the mempool.

Agreed that scalability is a valid concern. This PR documents the existing behavior across clients. The proposed txpool_transactions method with filtering and limits will address these concerns through the EIP process that's where we can design a more scalable approach.

I agree that perfect pagination is not worth, but if there is any use case for downloading everything, some kind of range could be passed, like responses are sorted by sender, so you can use the last sender as input for the next batch.

For example in Besu, the txpool is only bounded by the amount of memory you give to it, so if you configure 1GB there could be millions of pending txs in the pool.

Said that, I do not think there is any urgency in doing some sort of pagination now, I see filtering more useful to have as debugging tool.

is the format intentionally left free-form? who is the intended consumer of this API?

Yes, the free-form string format is intentional this matches Geth's original implementation the intended consumers are developers and node operators who want a quick human-readable summary of pool contents for debugging purposes, without parsing full transaction objects. If you need structured data, txpool_content provides that. txpool_inspect is essentially a convenience method for visual inspection.

So, if I got it right, there is no enforced format and the result will be implementation specific.
Will this be covered by tests? Could be hard to verify free form responses.

Correct the response structure is standardized (nested maps of address → nonce → string), but the string content itself is implementation-specific. the tests verify the structure returns correctly (pending/queued maps with string values), not the string format this is similar to how some debug methods work the structure is defined but content can vary.
I can add a note in the spec clarifying that the string format is informational and may vary between implementations.