I’m keen to understand more, specifically which networks are not supported.
The most prominent example is zkSync, but any type 3 or type 4 evm would pose this issue (see types of evms).
But even type 2 and 2.5 can pose these issues as the Safe singleton makes assumption about gas usage. We will remove this code, but this does not guarantee that the same singleton will be used on all chains.
A couple examples of this are for example BSC where some eips are not implemented (specifically EIP-2929 and 2930). Also on Ethereum Mainnet verbose event emission (which is used on the low gas networks to keep track of all interactions) is quite expensive.
As rollups come with the idea with being application specific it is a bold assumption to assume that all networks will work 100% the same (so type 1 evm).
whether it would be UI / UX improvement.
That being said having the same address on multiple chains is not only a technical challenge (actually this is probably the easier challenge), but a UX challenge. As the state of these Safes is separate you will experience state drift. Just because you own a Safe on one network you might not own it on another network, as owners change and different modules might be enabled.
This is what the proposal made here is addressing. How can we setup a system that works cross chain, where the user actually only has to know 1 address (the mainnet address and/or ens address). The rest would happen automatically.
Maybe to note: The proposal is not explicitly excluding deploying Safes on the same address on multiple networks, BUT it does not make the assumption that it is possible, because we believe a solution that works without this assumption is necessary.