One of the alternatives to package downgrades for problems like my concerns with trying Fedora Rawhide is what I'll call 'rollbacks': whole system snapshots that you can easily revert to. However, I'm far less enthused about rollbacks than I am about downgrades, and I don't think they're as good a solution for this problem.

The problem with rollbacks is that they are too comprehensive. In real life, you don't always detect problems right away, which means that you can wind up having also made unrelated system changes, changes that you want to keep. If you roll back to a pre-upgrade snapshot, you undo the upgrade but you also undo your unrelated changes too, and now you'll have to redo them (and perhaps track them down).

(At least this is my experience, but I think it's going to be true of many relatively non-minimal systems; if nothing else, you may not use certain features or programs very often. It recently took me several days to notice that I'd broken Flash in my browser, for example.)

This leaves me feeling that rollbacks are the wrong solution to this problem. They're a good way to handle something that breaks immediately (and a great way if you need really fast reversion to a working system). But they're not a focused solution in the way that package downgrades are, and so the further you from an immediate rollback, the worse their side effects can be.

In theory various change management systems can help you by tracking and perhaps automatically re-applying your changes. In practice I think that there are two problems with this. First, they're a lot of work to set up, especially on a one-off basis (and you're probably not going to have lots of machines in this sort of situation). Second, my experience is that some of the changes I make after upgrades depend on the new packages (I am customizing a new version of a configuration file, for example); if I roll back, I definitely don't want those changes to still be applied. There are semi-solutions to this, but they add even more complexity.