Can eth_getTransactionCount + NonceManager.getNonce together reveal the full transaction count for an account?

[bbaktaeho]

Describe the change

After confirming in earlier research that eth_getTransactionCount only reflects the protocol nonce (nonce_key =
0), I started using the NonceManager precompile's getNonce(address, uint256) (selector 0x89535803, at 0x4e4F…0000)
to read 2D nonce lanes.

But getNonce requires a specific nonceKey as a parameter — it doesn't enumerate. Since NonceManager.nonces is a
mapping(address => mapping(uint256 => uint64)), Solidity doesn't expose key enumeration, and the precompile's
INonce interface exposes only this one view function.

So the practical situation for an external caller seems to be:

• Protocol nonce — queryable via eth_getTransactionCount.
• 2D nonce lane k — queryable via getNonce(addr, k), only if the caller already knows k.
• Set of 2D lanes used by an address — not queryable on-chain directly. Seems to require scanning
  NonceIncremented(address indexed account, uint256 indexed nonceKey, uint64 newNonce) event logs.
• Expiring nonce (TIP-1009, k = U256::MAX) — not counted anywhere on-chain (hash-based replay, no counter).
  getNonce(addr, U256::MAX) always returns 0.

So even combining eth_getTransactionCount + getNonce(addr, k) cannot compute a full "transactions sent by this
account" count without also indexing logs or maintaining an off-chain index.

Questions:

1. Is this understanding correct — that a complete count cannot be computed purely from on-chain view calls, and
   that NonceIncremented event scanning (+ off-chain tracking for expiring nonces) is the intended path?
2. Is there a plan for an aggregation-friendly RPC (e.g. tempo_listNonceKeys(address) or a total-count helper) so
   third-party tooling doesn't need to scan historical logs for every query?

Thanks!

Additional context

No response