A side effect on RPC simulations that the EIP does not address, since it only specifies transactions: in geth master, eth_call goes through the same reservoir split as a transaction, so a call given 50M gas starts with TX_MAX_GAS_LIMIT - intrinsic_gas (about 16.76M) of execution gas and the remaining ~33M sits in the state-gas reservoir, which computation cannot use. After Osaka, clients exempted eth_call from the EIP-7825 cap (geth #32625), so views that compute more than 16.7M gas (on-chain SVG renderers, quoters, aggregators) work today with the default 50M RPC gas cap. Under Amsterdam they fail with a plain out of gas.
Repro against stock geth --dev --override.amsterdam 0 and the full numbers are in eth_call execution gas capped at 2^24 after Amsterdam (EIP-8037) · Issue #35838 · ethereum/go-ethereum · GitHub.
Question for the authors and other client teams: should simulations with no transaction validity checks run with the whole requested gas as execution gas, as they do post-Osaka? If yes, it may be worth a sentence in the EIP (or in execution-apis) so clients converge on the same behaviour.