NixOS tends to encourage "proper" solutions instead of hacky temporary solutions, so while doing stuff on NixOS takes more time, maintaining what you've done is much easier, and it's much easier to reason about, so I learned much more on NixOS than I learned on Arch (hell, I wrote two Nix DSLs for nftables and Lua because my perfectionism told me I need to do that instead of manipulating config as strings in Nix). I have an initrd hook that configures GPU passthrough by picking a GRUB option, I have a system configuration for an Arm router SoC (BPI-R3), which is a painful piece of hardware to work with, much like other SoCs, I have the router config itself (which I wrote a Nix framework for) - and if I ever forget how that all works, I can read the config to remember it, instead of trying to figure out what Linux commands I ran "back then". But if your goal is just learning about Linux, look elsewhere - that was just a bonus for me; Nix is an abstraction, and you can only start learning Linux after you understand that abstraction.
chayleaf
it looks like it's similar to SmokeAPI which is used by CreamApi, though SmokeAPI has much more code (I don't really know what for, it seems pretty bloated actually, but some of it is an improvement over my version), and more importantly SmokeAPI isn't crossplatform
kinda, preinstall/postinstall scripts expect to run on a clean system, while NixOS can be changed without a full system wipe, you don't need to redownload/rebuild anything you've already downloaded/built.
Simply use two different configurations? The more interesting question is how to share stuff between configs.
Each piece of config is a NixOS module. You can include some NixOS modules in one system's config, but not the other.
You know why reinstalling Linux is annoying? Because you have to remember (or write down) every piece of config you ever changed. Dark mode in KDE? Change it in settings. Some systemd unit tweak? Change it in /etc/systemd. Want to run some commands at boot? Use systemd (see above), or write an initrd hook (distro-specific). Need a specific version of an app? Need some files in /opt? Need certain packages installed? You better remember to do that!
In NixOS, you "reinstall" your OS every time you change a single setting, because reinstalling NixOS isn't scary at all - everything that needs to be changed is configured in your configuration - just make sure /home and /var/lib are saved (and perhaps some other dirs, I have root on tmpfs and bind mount all persistent files I need to ensure I know what needs to be preserved on clean reinstall and what doesn't).
Want to move it to a different PC? No problem, copy the files in /home and /var/lib and simply install NixOS using the configuration you already have on the new PC. Want to create a boot option with slightly different kernel or kernel options, or maybe even another DE? No problem, specializations got you covered.
And of course, this also means it's easy to share configurations for specific use cases. Want to run on some specific hardware that doesn't work out of the box? Perhaps nixos-hardware got you covered. Want a certain program set up? Maybe there's already a NixOS option for system-level config or a home-manager option for user-level config, worst case you can write it yourself and share for everyone else in the community using flakes, and maybe open a PR to nixpkgs/home-manager. Want to share configuration between systems? That's easy, put them in the same flake and write a common module shared between all of your systems.
Basically, if you're fine with whatever comes out of the box in any Linux distro, you don't need NixOS, but if you need configuration, if you run servers, it is a lifesaver. I switched from Arch, no regrets. I run my personal laptop, my server, which I effortlessly migrated from Oracle Cloud when they quit Russia, and my router on it, here's my NixOS/home-manager config.
The only downsides are the learning curve and the fact that you can't "just" run programs that expect a FHS layout. You can do it with workarounds like steam-run or appimage-run anyway, but overall be prepared to learn to package stuff for NixOS. Also if you have no experience with functional programming, the Nix language may be hard to understand at first.
Overlays don't "provide any options". Overlays simply extend nixpkgs or replace parts of it. You can search through all packages in nixpkgs here.