Every package has its own git repository which for binary packages contains mostly only the manifest. Sources and assets, if in git, are usually in separate repos.
This seems to not have the issues in the examples given so far, which come from using "monorepos" or colocating. It also avoids the "nightmare" you mention since any references would be in separate repos.
The problematic examples either have their assets and manifests colocated, or use a monorepo approach (colocating manifests and the global index).
The problem is that Arch doesn't need to quickly resolve (version -> manifest) for arbitrary versions. With Arch, /var/lib/pacman/sync/core.db has one release of a set of packages. When you install, you just grab whatever's there. Rolling release. pacman -Syu pulls the newest version of that set of packages. If you install sqlite 3.0 and then come back a few years later and "reinstall" all the Arch packages you used to have on a new machine, you'll either (a) use that exact database and pull the same version or (b) pacman -Syu, pull latest package database, and get the newest sqlite (say, 3.5)
There's no concept of installing sqlite 3.0 on a system where sqlite 3.5 is available.
For a language package manager, it's exactly the opposite. I could make a project with every version of sqlite the package manager has ever known about. They all must be resolvable.
If you want to do that resolution quickly (which manifest do I use for sqlite 3.0?), repo-per-package doesn't work without a bunch of machinery that makes it, IMO, not worth it.
Pacman is the best, you'd have to pry Arch from my cold, dead hands. Just different constraints.
Every package has its own git repository which for binary packages contains mostly only the manifest. Sources and assets, if in git, are usually in separate repos.
This seems to not have the issues in the examples given so far, which come from using "monorepos" or colocating. It also avoids the "nightmare" you mention since any references would be in separate repos.
The problematic examples either have their assets and manifests colocated, or use a monorepo approach (colocating manifests and the global index).