TLDR: Keeping old LLVM versions introduce bloat and require time to maintain. Removing old versions can make supporting new versions easier. This issue will help figure things out with removing old versions.
Yeah, it’s a necessary step to making sure Nixpkgs stays fresh. When I did the consolidation of packages into common files, I ran into a bunch of odd version checks. With the process of figuring out legacy LLVM version removal, we can simplify those Nix files. Simpler Nix files can mean less eval. But this will also mean less work overall in the future.
This falls apart as soon as you need everything to be modern but the toolchain or need it to interact with more modern components (i.e. graphics drivers).
Though, mesa uses llvmPackages_latest so it isn’t a problem.
@wamserma’s idea of pinning nixpkgs and then just importing whatever you need which is legacy could work. However, I don’t want to jump to that immediately. My idea is to add a warning to LLVM versions we wish to remove, would say something like LLVM 12 is marked as deprecated and will be removed in a future version. We would move everything we can off of that version of LLVM and then once the last one or two packages can drop that version, then it is removed.