Well the only real reason when it comes to Nix is that they aren’t declarative. For a lot of Nix users, the ability to describe every bit of software and all their settings in one giant config file is the draw. Not necessarily anything against Flatpaks themselves.

But I agree, I like being able to mix the two where it makes sense.

I believe that’s correct – if nothing has changed from your last generation, then the new generation will be identical. But if something has changed, it will do a bunch of duplicating and remapping symlinks in the Nix store to ensure that everything plays nicely together and that you can rollback to a previous generation if needed.

So if you do a rebuild switch regularly, you will end up with gigs worth of old “copies” of things that aren’t being referenced in your current generation.

That’s what nix-collect-garbage handles – once you know your current generation is working well, you collect the garbage and recover that space, at the expense of not being able to roll back.

That’s why I think building a core system with NixOS and then having user software come from Flatpak is a nice combo for simple workstation that won’t update and bork itself, leaving my grandpa without a laptop until I can come take a look.

Edit: To clarify, nixos-rebuild-switch won’t update your Flatpaks at all – just the Flatpak service