NixOS boots to a menu of system configuration revisions to chose from which includes any config change, not just kernel updates.
It's not filesystem snapshots either. It keeps track of input parameters and then "rebuilds" the system to achieve the desired state. It sounds like it would be slow, but you've still got those build outputs cached from the first time, so it's quite snappy.
If you took a bad update, and then boot to a previous revision, the bad update is still in the cache, but it's not pointed to by anything. Admittedly it takes some discipline to maintain that determinism, but it's discipline that pays off.
I don't expect to use it much myself but I love the idea of reducing the OS to an interchangeable part. What matters is the software and its configuration. If windows won't boot for some reason, boot to the exact same environment but on a different OS, and get on with your day.
If something is broken about your environment, fix it in the code that generates that environment--not by booting into safe mode and deleting some file. Tamper with the cause, not with the effect. Cattle, not pets, etc.
This sort of thing is only possible with nix (and maybe a few others) because elsewhere "the exact same environment" is insufficiently defined, there's just not enough information to generate it in an OS-agnostic way.
It's not filesystem snapshots either. It keeps track of input parameters and then "rebuilds" the system to achieve the desired state. It sounds like it would be slow, but you've still got those build outputs cached from the first time, so it's quite snappy.
If you took a bad update, and then boot to a previous revision, the bad update is still in the cache, but it's not pointed to by anything. Admittedly it takes some discipline to maintain that determinism, but it's discipline that pays off.