Though unfortunately (or I guess for most use-cases fortunately) you can't find the malicious m4/build-to-host.m4 file on there afaik. The best way to find that now, should you really want to, is by looking through the commit history of the salsa.debian.org/debian/xz-utils repository which is, as far as I understand it, the repository that the debian packages are built from and consequently also what the compromised packages were built from.
I don't think OSTree systems can quite reach the flexibility of NixOS. For instance with NixOS (with direnv and nix-shells) you can essentially swap out your running system based on the different directories you enter and I think that's still just scraping the top of the iceberg. From my experience with OSTree (which is admittedly somewhat limited) I don't think you can reach that level of flexibility.
It's still really cool, I don't mean to shit on that, I'm just saying NixOS and OSTree have different pros and cons and use cases.
I started gaming on Linux at the beginning of 2019, that was afaik half a year after Proton was released, and I still remember how rough around the edges it was. Back then it still felt somewhat like a coin flip (the odds in reality were obviously a good deal better) if a game ran. Seeing how much they improved it over the last 5 years is really quite something.
If you use the GNU libc the feenableexcept function, which you can use to enable certain floating point exceptions, could be useful to catch unexpected/unwanted NaNs