FWIW, uBlue has been brewing for almost three years now for their CLI stuff: see this issue tracker and this blogpost from Bluefin's creator.
The distrobox workflow overall has mostly been superseded by better alternatives^[There's sysext with its (WIP) manager, Brew Tap to tap into homebrew casks and some peeps even use coldbrew. And last, but definitely not least, nix support has improved over the years. And if you just want to use dnf, RakuOS' innovative hybrid design allows just that; an image-based core you can't touch (like the other 'immutables'), but dnf works and is applied through a persistent overlay.]. Though, for completeness' sake, openSUSE's atomic offering continues to heavily rely on Distrobox. But, in their defense, I think their atomic offerings are simply better^[Fedora's container images are tied to its major release versions. Hence, every 7-13 months you're required to set them up from scratch if you'd like to continue using them 😅. Even if this process can be streamlined, it's IMO very cumbersome regardless. In openSUSE's case, the containers are based on Tumbleweed. Which, has a rolling release cadence. Hence, it was meant to be used indefinitely.] suited for it.
It has been my pleasure 😊. I really appreciate your kind words 🤍.
Absolutely. But, I think it's nuanced and the lines are becoming increasingly blurry. If something based on Fedora can become something based on Arch (and vice-versa), if almost any distro has multiple releases/channels/braches, if software for/from any distro can be installed on every other distro, then... at what point is it truly "around these parts" rather than "with those not-hardcoded system specifications"? Kinda like how DEs can be (un)installed, and how those come with implications on how some stuff is done...