I really do wish I could help, but I don't know how to reconcile what I'm reading as a mutually exclusive desire. If I'm interpreting you correctly, it sounds like you recognize what you're after requires complexity, and that Bedrock appears to be a potential solution because it offers the requisite level of complexity, but you don't want to use Bedrock because of its complexity. I don't think anything can be complex enough to meet your needs, while also not being complex enough to meet your needs.

> One thing is managing all the /bin links and taking care of all the directory mappings that are needed. Say env-A calls gcc which is installed in env-B: First, env-A needs a wrapper for all gcc packaged binaries - and those wrappers need to ensure the current directory stays the current directory, /bin and /lib become merges of env-A/env-B, etc. It gets hairy and I'm not sure what's even needed - I haven't done something this complex.

Early Bedrock releases, circa 0.1, had a utility that walked through the $PATH for binaries for each environment and generated wrapper scripts for binaries which cross the environment boundaries. It dumped these scripts in the $PATH after the environment's native binaries would be picked up, if they exist. While I don't remember if I ever did it, the re-running the utility could be automated with either package manager hooks or an inotify-based daemon. The main problem with this workflow was the time to wait for the utility to re-run whenever the collection of wrappers was problematically out of date. Things like having Arch's bash run `apt install htop && htop` wouldn't work due to the utility's runtime delay.

Code is generally easier to write than read. If your complexity concerns would be alleviated by having written something yourself - so that you know you understand it - you could try to mimic this approach.

> I think I read bedrock has fuse for managing links which seems like the level of complexity that's needed.

Yes, Bedrock has a FUSE filesystem which does the equivalent of generating the bash wrappers for binaries on-the-fly. It also handles translations needed for other resources; things like altering the `Exec=` lines in `.desktop` files for application menus. Other files it just forwards unchanged, like man pages. A long term goal is for it to support translating service manager configurations, so that one distro's init can run another's services without any manual intervention needed.

> My ideal setup is a base system which is fairly minimal, but handles boot, init and kernels for sure. And then isolated packages on top (docker, flatpak, nix, homebrew, distro-chroots) which do integrate with each other when needed.

While I don't intend to push you to Bedrock - I fully agree it's more complex than a traditional distro and at this point you've well established the fact you find that off-putting - this description does sound a lot like Bedrock to my ears. The only differences I see are (1) Bedrock's optional ability to let those "on top" "packages" provide the bootloader, init, and kernel and (2) the term "distro-chroots" instead of Bedrock's term "strata."

-----

When the next major release of Bedrock, 0.8, is released; you could certainly try out the official container-like solution for it and see if that meets your needs. This should be adequately segregated from the host environment while still internally integrated. Absent that, my suspicion is that you'd be happier having written your own solution here. This way you'd understand the capability-complexity trade offs and made exactly the balance you find best. You also wouldn't have to worry about the possibility there's some corner of the system you don't understand. It might not be as capable as Bedrock - I've got quite a head start on this - but it sounds like you don't need it to be.