Hmm, that's just the initial configuration, though, right? If you want to roll out updates to the config, you would presumably use Salt or similar (like they have a config field in that generator).

That's also an improvement for this use-case over your average Linux distro, especially because MicroOS is immutable as well, but NixOS is still a big step further into this direction.

I guess, what I really wanted to say in my previous comment is that NixOS isn't just immutable, but rather also declarative.
You define your system config and then it makes it so the system matches that configuration, whether it's a new system or a previously installed system.
So, it's not just a script where you need to describe how to apply or unapply a change, but rather the entire OS declared in a config file (and a ton of defaults).

The big difference is that you know the state of a system, when you apply a configuration. It is written into your configuration file.
Whereas with a distro which is merely immutable, even if you completely prohibit users from making changes, you still have the problem that someone might've been on vacation while your script contained a line to e.g. modify some config file.
If you update that line before they return, then you better hope your new modification logic can deal with whatever is on their system.

With a declarative system, this cannot happen, because the contents of that specific config file would be defined in your NixOS configuration file. No matter when you do the sync, the up-to-date contents will be put in there correctly.

(And yes, I know, if you get your scripts right, you can achieve similar results. The point is that you don't need to.)