In PR Update EIP-7702: updates for devnet4 by lightclient · Pull Request #8929 · ethereum/EIPs · GitHub the chain_id size was limited to uint64. This unnecessarily restricts the chain_id to be a vanity ID, chosen arbitrarily like many EVM chains have today, rather than more like a hash.
In other places in the protocol, a full uint256 chain ID is supported.
A large chain ID like that can be chosen by hashing some state and/or configuration, enabling the idea of a “counter factual chain identity”: a chain instantiation bound to its usage rules. For future more ephemeral chains this is ideal, as a user does not need a central registry to update to attach specific rules or configuration, those can be proven against the chain ID instead.
And this can expand into neat protocols where the user signs transactions in advance, and the chain is only instantiated when certain conditions are met, exactly with the rules and pre-state as committed to by the chain ID.
This can also be a big part of making chain configurations more interoperable and chain-instances more elastic, as there is no need for a central registry to register the chains in a uint64 namespace.
Disclaimer: I did not come up with these chain ID schemes, these things go back as far as 2018 comments on ethresearch sharding threads, likely earlier. @vbuterin might be able to share some history about the general idea.
Can we please revert this chain_id size limit in EIP 7702, and support full uint256 chain IDs in the auth list?