I’ve been one of the earlier proponents of Snapshots. If this tool worked it would be an awesome addition to our workflow.
Currently they are buggy and dangerous. So we only make snapshots to files when there’s no more design/modeling work to do. And when we are ok to completely destroy that file.
We see these main problems:
- file size/memory and performance issues (they can get real slow to load)
- we cannot add new content to files (new layers, new objects, edit objects in ways that object IDs change (like explode and rejoin with new edits) and have any certain of what will happen.
- we cannot make changes and be sure if we are making the change globally or to a particular snapshot (why don’t we have a big red bar in the viewport telling us that we are in Snapshot editing mode?)
- snapshots are not supported in layout mode. So we cannot load different snapshots to different details. Snapshots has one job: save and restore various states, and what’s the point of doing that if you cannot document it in layouts? …but layouts is a conversation for a different topic/year/rhino-version.
- we have no way to know if materials that are not currently in use (but are used by a snapshot) and materials that should be purged
- we have no way to add objects to already saved namedpositions states in snapshots. @pascal worked out a scrip to fix this, but it’s still too confusing and risky to use.
- no output of all snapshots as images or animations (@nathanletwory did write a great script for the images export, it should be part of the built-in functionality)
- previews don’t work so you save snapshots and have no way to visually know which one you already saved, or choose which one to load again.
…Feel free to add anything else to the list. We are so scared of them that we used them very sparingly so we have not uncovered all its ways of betrayal 
This tool has never lived to its potential. It was never designed or coded with the level of attention to execution and follow through it deserves, especially when it comes to Q&A and testing, something that McNeel continually expects us the customers to do. The problem here is that it’s such a work-wrecking tool that no one will want to put any effort into it.
Snapshots needs a lot to work from McNeel to be useful, reliable and stable. And only then, they will be awesome. I’ve been asking for this for about 15 years, since I started using NamedViewManager script (I believe was from @ThomasAn_?), including giving a live demo at a lecture in Colombia in 2014 where I showed live changes of design and configuration variants all running in a live Rhino session using namedviewmanager and the audience loved it, Bob and Don Andres Senior were there, so it was a bit of activism on my part when I told the audience they could all have this if they told Bob and Don Andrés they wanted it. So this shows you how long I’ve been a ‘Snapshots Activist’.
Snapshots will be absolutely great, but right now they aren’t. They are a great idea very poorly and partially executed, and with zero regards to content integrity and safety.
McNeel team, are you aware of this? Where do you see it in terms of importance and priority of effort?
Thx,
Gustavo
PS: The activism will continue until Snapshots improve.
PSS: I edited my poor grammar and poorer iOS auto-correction