Because that dependency is in the meta-package's manifest. Realize that I'm talking here about an entire ecosystem of "meta-package formulae" that contain instructions to make particular tool-calls on particular systems.
> What version of that library would it use? How would you reconcile where each package manager installs things? Traditional system package managers install to the global /usr directory. npm makes nested directory structures anywhere. Brew installs to /usr/local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized?
You wouldn't reconcile any of these things, any more than things are reconciled now when you "brew install" one thing and "gem install" another and "npm install -g" a third. The result is a heterogenous multi-runtime system, but it continues to work, because each tool knows how to manage its own ecosystem. A meta-package manager would call through to the regular package managers as its API for each ecosystem.
> How about package managers that require root privileges vs. unprivileged ones?
The meta-package manager could assume the existence of a self-elevating wrapper tool like Debian's wajig(1), and provide such shims for package managers that don't have one.
> What software bootstraps the entire system?
The regular OS package manager.
---
I don't think I'm being clear here; the point wouldn't be to replace the system package manager. The point is to automate the use of all the various package-management tooling for configuration management in a unified, declarative manner.
I would expect the meta-package for e.g. Postgres to look a lot like a Chef cookbook for installing Postgres, but with the limitation that—where a Chef cookbook would first attempt to use a package manager, and then "fall back to" mutating the system itself in a way no tooling on the system is tracking—a meta-package would instead just fail the installation if there was no package-manager source satisfying its constraints.
Guix is great, but it is its own OS with its own ecosystem. The point here would be to unify the API to package management on the ecosystems that already exist, such that you could interact with the package manager in ignorance of its host OS the same way you can currently interact with e.g. a Docker daemon while ignorant of its host OS.
If this tooling was available and baked into server VM images and so forth, you could, for example, mostly replace the "cloudinit" instance-initialization system with a simple package list; or create something like a "virtual AMI" that takes a parent AMI ID and a "[{package, version constraint}]" list, and derives a new child image to launch on a set update schedule.