If you had written this as a question rather than a definite (and somewhat aggressive) statement I might've explained it to you.

Pretend I asked the nice version of this, for the benefit of other readers?

I do think a Nix-like tool to be used for writing/replacing package managers for new programming languages would benefit from some dependency resolving functionality, instead of just saying 'shove it in a monorepo or pin via VCS refs instead of semver'. Is that not necessary?

Nix is capable of that, but you need a database mapping versions to VCS refs.

Nixpkgs doesn't go down that road because it would be unwieldy at their scale, but more specialized nix-based tools do.

(I actually think Nixpkgs could and should go down this road, with a couple of caveats, for immense benefit. But I'm curious about what tazjin thinks here.)

At least for (unlocked) flake sources, you could probably use a branch naming convention instead of a separate database, although that requires your repo to be set up a specific way.

Nix is an umbrella for a stack of various solutions.

Nixpkgs doesn't do version or feature resolution, but other tools (that are not nixpkgs) can and do.

Under this abuse of terminology, a pocket calculator is capable of becoming a package/dependency manager. Or any other technology which conceivably could be put to work toward the package management problem, but has not yet been adapted to that need. I concede that these statements are "true", but they fail the relevancy test of communication.

Like I said in another comment, the problem is curating the giant database that maps version numbers to commit refs. Once you pass this roadblock, the tools Nix gives you make dependency resolution a quite a bit simpler problem to solve.

The next step is then realizing you actually don't need the useless legacy version numbering scheme at all, and that you wasted that effort for nothing.

Something like this maybe? https://lazamar.co.uk/nix-versions/

I'm not sure what you mean, through, by not needing the actual program versions.

What we actually want is a content-addressable global namespace of source code. (Maybe it could be marketed as "blockchain for software" or something, lol.)

Version numbers are an attempt at content-addressing from the time when software came on floppy disks and CD-ROMs. It sorta made sense given the constraints of that technology.

Nowadays trusting git tags over git revision hashes makes no real sense. (Except that git tags are kinda shorter to type, but who cares.)