Hmm, not sure what you mean by this. There’s two distinct ideas:
- Individual storage slots of a contract are migrated to newer epoch state trees separately
- There’s the possible extension of allowing a contract to have storage in different address spaces
I don’t think (1) would change how the EVM or any programming languages work. It would still look like how things work today, except that your transaction will sometimes have to come with renewal witnesses for specific storage slots.
For (2), I agree that it would be a big change to how contracts work. There’s already the simpler alternative that if contracts want to have storage slot spaces in which they can add new content freely without witnesses, they can just create child contracts in newer address spaces.
There are also other alternatives we haven’t explored yet; for example, a contract can have a counter of what its total storage slot count is, and a counter of the number of storage slots poked in the current epoch, and if the two are equal then we know that the contract has been fully migrated forward, and we can just move the entire contract into the latest address space. Though that would add some implementation complexity…