I have spent some time thinking about how to describe how State Sets should work properly in the most clear and comprehensive way possible. And i have came up with the way of designing and testing state sets that should be as production-proof as possible. Here it goes:
1, You have a reasonably complex finished scene setup. Then you create a new state, and enter that state. Once you enter that state, you can do any sorts of crazy things without being careful at all. You can do anything and everything you need in order to set up the pass you want, without need to be careful about absolutely anything except doing physical changes to the scene. That means deleting objects, moving, animating them or changing meshes at their base (non-modifier) level.
2, Then once you exit the state, everything is exactly 100% same, as it was before, and if you render again, you get to the pixel same result. In case new objects were created in the process of setting up the render pass, then these objects should be hidden from the base pass and other passes for both viewport and render, so that what you have is 100% identical to what you had before you started to work with different state.
3, You can again do absolutely any changes in your base state, except deleting objects, moving, animating them or changing meshes at their base (non-modifier) level, and if you return to your render pass, that you had set up before, everything will again be 100% the same as before… and if you render again, you get to the pixel same result again.
4, At the creation of states, there would be two options - Clean state, and Reference state:
Clean state would mean there are no connections to the base state, so for example changing render settings resolution or environment map in base state would not be propagated to this state.
Reference state would mean that any options, be it render settings, object viewport/render visibility, materials, environment and so on would be always referenced from the base state unless you change them, once you change one, it would become unique to this state.
5, Most important rule. Any non physical changes (deleting objects, moving, animating them or changing meshes at their base) made in any state except the base state can NEVER EVER, under ANY circumstance affect base, or any other state.
6, Then of course, there would be sub-state system, which would be a reference state, that would not reference settings from the base state, but it’s parent state instead. That would make a single exception in point #5, where non-physical chances in non-base state are propagated to all of the sub-states, except for those changes, that were made unique in in sub-states by being changed.
So basically i would think of it as many scenes contained within one scene file, that together share objects, their position, animation and base level geometry of meshes.
In my opinion, if it worked this way, according to these simple rules, and was stable and bug free, it would be both pleasant and efficient to work with. Design that breaks any of these rules will be always very prone to problems.