Probably the closest thing to that combination you speak of is the merge project feature, described in §5.3.2, under subheading, Merging Changes from One Project into Another. (Note: a Mac-only feature at the time of this writing.)
The idea here is that you would create a milestone backup for safe keeping, then continue editing for a while. When you wish to review everything that has changed, you would create a copy of the backup (important) that is strictly meant for comparison checking—something to dispose of later most likely. From that copy, you would import the current project and select the option to merge changes, when asked.
What that does is then build a Collection of every binder item that changed, and it will automatically snapshot all of those changed documents as well. So now you can go through and audit each change, using the Snapshot compare feature to help in that process. The key thing is that at this point both the current project and the one you copied and updated with the current project should be similar. So you could select one of either to discard if in reviewing the changes you change your mind about one thing or another. But do bear in mind that project merge is chiefly concerned with merging the binder itself, not the project settings. If you’ve made significant changes to the compile setup for example, Merge does not handle that. So in most cases I would advise only using the merge copy as a reference.
The question is whether that approach is efficient for how you work. On the plus side, you don’t really have to do much yourself while you work. You don’t have to remember to take snapshots. You don’t have to remember to turn revision mode on or off—you are depending upon the software to do all of that for you. So that can be a significant advantage to those that have a hard time forming habits of “documenting” their work as they revise. The downside is that it is a bit involved, requires a lot of project juggling, working in duplicate copies and keeping straight which is important to keep and which is disposable, etc.
Forming good habits gets you to the same place as the procedure described above, and of course since the machine isn’t doing it all for you, it allows you to personalise that procedure—to choose when a revision is significant enough to document, to maybe use a tool other than collections, etc.
On the matter of documenting revisions, I might as well link to this post. I don’t always use this approach, as it has a lot of overhead, but for projects where it is really important to know what changed, and why, it creates an invaluable track record and level of self-documentation to the project.