> They certainly both suffer from issues related to upstream packages doing their own thing.

Having used both Bazel and Nix, I agree they suffer here but with a slightly different take: They suffer because they must reinvent the wheel and provide a new API to mimic the upstream package managers. They're in a constant race to keep pace with best practices outside of their community - and patch their APIs accordingly which become "dirty mirrors", only partially reflecting the intent and functionality of upstream tooling.

But that's kind of the point - they apparently need to take over and constrain the system to fully understand the dependency tree.

I wish there was a Bazel/Nix/Guix build tool that had some barrier between the dependency tree and the developer tools that one uses daily. When I'm building the system as a whole, I don't want to think about cargo vs npm. But when I'm writing code for a given component, the native tooling is the correct abstraction. Is it even theoretically possible to resolve those two ideas without introducing another glue language?

There is https://github.com/tweag/rules_nixpkgs which is something I wanted to look into.