For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof.

Granted Btrfs sounds great though, i've not used that. It would certainly help.

Yeah that's true. That's where the "largely" part of my comment does some work.

I just take occasional snapshots before I do things that I'm concerned may be catastrophic. But it definitely won't catch everything. It helps that I run Arch, and I update packages once a day, which only leaves me with under 40 (small) packages usually. So a quick cursory glance at which ones are updating usually tells me what to be cautious of. Display driver update, kernel update, etc.

If I'm not sure what went wrong, but I at least have a working snapshot, then I can get done what I need to get done, and then go back to troubleshooting. Rather than just having a broken system regardless.

I used to employ ZFS for this, but if it took me a while to notice something was broken, or I updated multiple times, it was annoying to figure out which snapshot was the issue, and which changes actually caused the problem. On NixOS, I just have to select a different generation in systemd-boot, and since my configuration is stored in a Git repo, they're all tagged with the data and commit hash they were built at, so it's very quick to a) find a working generation to just use for now, and b) actually find where the issue is and solve it.