acid-state should be affected, though to a lessor degree.
1. the name generated by openLocalState will change. This can be worked around by renaming the state directories on the disk or by using openLocalStateFrom
2. the event names in the events file will also change. This can be worked around by creating a checkpoint before upgrading so that no old events need to be replayed
There is also now a new possible issue that could arise. If you use openLocalState from on two types that have the same name but come from different modules, then they will both end up in the same state directory (causing a mess). Or perhaps openLocalState has some sort of locking mechanism that prevents that?
In any case, I am not sure if any of these issues warrant making a change to acid-state since they user can work-around all of them. (That was not the case with happstack-state).
If we leave acid-state as-is, we should at least make a note of the issues and the workarounds.
- jeremy