I may be reading too much into what is essentially an edge case, but I think there is a larger question of what we should expect or have options to request when changing from one project to another.
Currently, if a flow has un-deployed changes, the editor asks whether they should be deployed before closing the project. This is clearly necessary. In a previous thread, @knolleary suggested having an option to automatically commit changes to the project repo on each deploy or, as I suggested, when switching projects. In the same spirit, perhaps there should be an option to either retain or clear context variables when exiting a project. This could avoid the situation @zenofmud describes. It would also prevent a situation that may actually occur more often. If a project under development stores persistent context variables, they will effectively be initialized each time the project is re-opened. This may be what the developer wants, or it may have peculiar side effects that complicate debugging.
I am well aware that this final suggestion runs afoul of the current architecture for local filesystem context storage, but I think it would be ideal for each project to have its own context directory tree, with the ability to control retention independently. Implementation might not be hard, along the lines of how flow.json files are managed with and without projects enabled, but it might also not be worth the trouble.
