I agree that if chainId was the only thing to change, we would be fine. That is why I mention the (chainID, blockNumber) pair.
The need for blockNumber was discussed as part of our conversations.
It is explained here : EIP-1959 Valid ChainID opcode - #5 by wighawag and in the rationale of EIP-1965
It is to allow fork led by minority to not suffer from replay issues from the majority inaction (since the current chainId from the majority chain would be a past chainId on the minority chain). The blockNumber at which the message was signed can ensure replay protection by making smart contract disregard message signed at a blockcNumber where a chainID is a past one.
with EIP-1965 it simply expressed this way :
require(validChainId(message.chainId, message.blockNumber), "invalid message on that chain");
And by letting wallet setting the blockNumber as part of EIP-712, they protect users from replay issues.
A protection that EIP-1344 can’t handle properly since the required caching mechanism would leave a gap.
While it is technically true that they do not require it to function, they require it to function as expected. Indeed, smart contract that disregard past chainID will render their user dependent on the message submission timing. For example, a user could not rely anymore on being able to delay a message, since as soon as a hardfork happen, the user would have to sign the message again. This is less than ideal and why I think we should consider all application as benefiting from respecting past chainIDs.
But we should probably discuss that in EIP-1344 discussion thread if my comments there were not clear enough.