So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy.

Ultimately if you have too many gc roots you have to make some decisions.

It appears that Flox uses flakes and versions the flake.lock file, so it should be possible to readily reproduce anything that hasn't completely disappeared from the internet.

On NixOS, you can then configure background GC to clean up the Nix store periodically: https://search.nixos.org/options?channel=23.11&from=0&size=5...

https://nix.dev/guides/recipes/sharing-dependencies#complete...

It tracks nixpkgs-23.11

Now at the bottom it links to an example of pinning without using flakes, but the page you linked directly does not pin nixpkgs.

Flakes pin by default, and defaults matter. Using flakes, anything that isn't explicitly listed with a hash to ensure it's unchanged must be explicitly listed as an input, and a lock file for the inputs is automatically generated.

Also there are literally thousands of insanely complex things happening behind the scenes every time you use your computer. Not sure why Nix is considered special when abstracting over it.