Sometimes I put Nix talks on for background noise or to settle down at the end of the day, as a way of keeping an eye on how and where Nix is received in the wider tech community. I’ve seen a lot of intro-to-Nix talks. This is one of my absolute favorites. 
I’ve been daydreaming lately about how if NixOS could sustain LTS releases, it would allow for a nice workstation OS with escape hatches, kind of similar to Fedora Silverblue. You could link each LTS release into a location like /lts/1.0
, or into a bunch of directories like /usr/1.0
, /lib/1.0
, etc. The versions of libraries in an LTS are supposed to be ABI compatible and have identical behavior across updates, so users could link against and refer to paths in those locations ‘from outside the Nix world’ without running into trouble. SIlverblue has Flatpak as an escape hatch, but a similar system built around Nix would also naturally have Nixpkgs (which is nice because Flatpak is a little heavyweight, Flathub doesn’t contain many (any?) CLI utilities, and sandboxing is unnatural for a lot of common CLI utilities).
This would be really nice for allowing Nix-at-your-own-pace, like users get on macOS and non-NixOS Linux, on top of a base system built and managed like NixOS. It would confer the additional advantage of allowing multiple versions of the stable base system to be installed side-by-side, which might be interesting to companies like Red Hat and their customers as a way of easing transitions between major releases.
There’s also another possibility with such a system, probably of little interest to Acolytes of The Nix Way™ like us, of ports systems that target individual stable releases as their base systems. For people who just want a stable OS that works (and may or may not be interested in functional-style package management) and enjoy a clear separation between the base system and user software, like you get on macOS or *BSD, this could be a real benefit. What some people like about Homebrew or MacPorts or Pkgsrc is that they’re ‘simple’ to use (in a familiar, imperative way), and packages are not isolated, but those systems don’t (or try not to) affect the base OS, and if they misbehave you can easily blast them away entirely. One of the pains users of such ports systems go through is that they can break and/or require lots of rebuilding when the base system is upgraded. With a base system based on stabilized/long-lived releases of Nixpkgs, much of that breakage could be ameliorated. At the same time, the isolation that Nix packages have would help immunize the base system against meddling by those kinds of ports systems, even when the base OS relies on a runtime (say, Python) that users of ports systems might want to manage via those ports systems. Immutable root filesystems that still rely on the FHS, like current applications of OSTree, are cool, but they don’t share that virtue.
The missing piece for all this, of course, is a (probably smaller) fork of Nixpkgs with long-lived branches where stable releases of software get backported security patches.
Maybe it’ll never happen, but imo applying Nix or a deeply Nix-like approach to distros with long-lived releases like RHEL would allow for some really cool downstream possibilities.