My experience is as a package maintainer and as a downstream maintainer of Lix: we target the current release version in CI and unstable gets tested by users.
Even the release version of nixpkgs is very annoying to maintain. I think as nixpkgs we have it hugely worse than most distros: most distros have reasonably independent packages, no in-tree lib, etc. Because we target the release version in Lix, all the bugs in nixpkgs we find get fixes backported because we want the bugs gone on all supported releases. Sometimes these backports require modification to work without renamed internals.
The worst period is the month where there’s three releases technically supported (n+1, n, n-1), and the correct move there is to just move Lix to n about two weeks in and let everyone on the old version can just deal with 2 weeks old Lix HEAD.
I’m saying this to illustrate: this job of maintaining old branches sucks a lot more than the average distro and more closely resembles maintaining 500k lines of Python than a Linux distro. I don’t think the community is really sufficiently resourced to care about the 6 month old release, especially at the end of its lifecycle, let alone a two year old release. At the end of the cycle backporting anything is very annoying because of conflicts and architectural changes.
Another difficulty with a longer supported release than 6 months is upstream support: upstreams may reasonably just not want to deal with old stuff.
I personally look forward to deleting all the janky Lix workarounds for fixed things in stable after each release, and personally I would push back strongly on supporting Lix whatsoever on an older release of nixpkgs than 6 months because it requires that we would have an LTS branch, or tolerate old toolchains (and old nixpkgs infra), or build with new toolchains on the old nixpkgs (still old nixpkgs infra). Though I think we are the absolute worst case scenario because our internal CI depends on nixpkgs test internals in a manner that makes us effectively a detached part of nixpkgs, alongside a wide array of packages among other details (example breakage: xonsh changing how their unwrapped derivation works in 24.11).
At worst we’d have to have a Lix LTS branch but again someone should be paying for maintaining that, it’s very labour intensive to backport things and is equally expensive when bug reports show up that don’t affect stable, something which “too bad, upgrade your nixpkgs” avoids. For an evergreen project with extensive beta usage of HEAD builds, that’s wasted effort that could be put into simply rolling a new major release.
So an LTS scheme would likely be doing security backports.