The community has built two LSPs, and https://search.nixos.org/options (or "man configuration.nix", if you prefer) shows what NixOS options are available
NixOS and flakes are orthogonal. Flakes are not a replacement for NixOS, they are simply a _lockfile specification_, akin to your requirements.txt or Cargo.toml or such. NixOS is not legacy.
It's more like 7 months of patches. Release (n-1) gets EOL'd 1 month after release (n), and releases are 6 months apart (in May and November). So 23.11 would've been EOL in July 2024.
And since a release happens every 6 months, while you do have an extra month's window, you still have to upgrade... every 6 months.
nix is a build tool, not a package manager. Misunderstanding nix as a package manager (and the dumb marketing on its website) is what leads to frustration (along with, of course, docs).
From the vendor side, it's more like the software equivalent of dropshipping. Slap your own label on something you didn't make and call it a day. If the original "manufacturer" goes under, you either pivot or fail too.
From the consumer side, if you buy a dropshipped product you don't get the benefits of working with the manufacturer, and are risking worse customer service.
I see people usually use the term "premature optimisation" to mean "I wouldn't think about this thing, so no one should". Also people really take that one quote and consider it gospel, forgetting that "premature" is contextual and subjective.
Meanwhile I think it's a bit silly that they didn't have a plan B for 425 TiB (!) of data and are scrambling to figure it out now. It's not about "fixing problems that don't exist", it's called "planning ahead for a scenario that is practically guaranteed to happen" and has high risk for the future of the project if they don't have such a plan.
They created essentially a SPOF where "failure" was losing the financial goodwill with some company.
