When such hard fork is announced, it is likely that the hoarding of the state will begin (get it while it is cheap!). Blocks will probably fill up with the state expanding transactions, and the gas prices will shoot up again. This situation might persist until the hard fork. And then, when the high costs are introduced, those who hoarded the space, will need to return their “investment” and will try to form what I call a Dark Rent market . I have not figured out the mechanism, but I think it is technically possible. The difference between this and the State Rent that is being proposed so far, is that the beneficiaries of the Dark rent are the hoarders, and the beneficiaries of the “Light” Rent are all ETH holders collectively (because rent gets burnt).
It’s worth noting that there is a “keyhole solution” to this. For each storage key, store whether or not it has already been accessed after the fork. If the old new-storage-slot cost is STORAGE_SLOT_OLD and the new cost is STORAGE_SLOT_NEW (eg. 20000 and 60000), then if a storage slot is modified that has not yet been accessed after the fork, charge an additional STORAGE_SLOT_NEW - STORAGE_SLOT_OLD gas.
The flags also have a secondary function, which is that they can be used to calculate over time the number of nonempty storage slots in each contract, which is needed to properly charge rent to contracts if that ends up being implemented later.
Alternatively, if we decide that we have access to a “tell me how many storage slots this contract has now” method (this could be done safely for large contracts by storing values in the client’s database that start at zero or whatever the storage slot count is at fast-sync time, then updating them as blocks are processed), then we don’t need per-slot accounting; we can just store a variable “number of storage slots not updated”, and charge an additional STORAGE_SLOT_NEW - STORAGE_SLOT_OLD per write until this “debt” is paid off.