To me that’s the most likely scenario. Fork that can be contentious do not happen by surprise.
And yes the idea as I mentioned earlier was to use @fulldecent proposal but it work without it being hash based. The only thing necessary is to update the chainId on every upgrades so that it does not conflict with a previous or existing chainId.
Actually we can make it a process so that a new chainId is attributed to each side of the fork at every proposed changes.
At every upgrade, client software implement 2 paths (activated on command line for example), one with the changes proposed and one without any changes (except for the chainId) and each with a different updated chainId. Then if the fork is contentious part of the community will run the chain with no change (except for the new chainId), the other part will run the chain with the changes (with yet another chainId)
The opcode I propose guarantee that in such situation, contracts can continue using it without affecting their user’s previous messages