I will make it simpler to understand. There is only one thing that make or breaks package resolution: do you support diamond dependencies and when.
A diamond dependency is when you have package A depending on package B and C. B depends on package D@v1 while C depends on D@v2. V1 and V2 are incompatible versions of D. This is a classic dependency conflict problem and whether you can resolve it automatically and bundle both packages into the final codebase/binary is the most important architectural decision of the package manager.
Package managers/ecosystems that support diamond dependencies in most circumstances:
Npm (as long as it's not a peer dep), Golang, Rust, Java/.NET (with shading enabled, it's not turned on by default).
With diamond dependency support, in most circumstances you can have arbitrary depth /complexity of dependency resolution.
If you don't support diamond dependencies (basically the rest of the world, Python, Ruby, Dart, Elixir, most lisps in their default setup, statically linked C/C++ in default configurations, maybe Zig too, I am not sure about that one), your dependency tree size is severely limited and it becomes a pseudo SAT problem in some cases if you want optimal dependency resolution.
This is the core algorithmic and architectural limit on package managers. Almost everything else is just implementation and engineering details. Stuff like centralized vs non centralized repos, package caching proxies, security hashes, chains of trust, vendoring, SLSA/SBOM etc. can all be bolted on as an after thought but supporting conflicting upstream dependencies simultaneously requires compliance on the bundler/transpiler/compiler level.
It's also why some languages lend themselves better to tools like Bazel that micromanages every single dependency you have while others do not.
Geo-tagging even deviations on Street Maps.
à la Carte, the formal way is contingent on whether intermediate representation of dependencies, are "enable[d] as translation between distinct package managers."
(author here) I also gave a talk on this work at FOSDEM this year: https://watch.eeg.cl.cam.ac.uk/w/iPX1Xx8LAZnuhojVYbyvAB