> It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part,

I'm not even sure it's mismanagement, just incompatible approaches. Debian ships a coherent system, with a minimal (preferably one) versions of each library per version of the distro, and each version of the distro is maintained together for a fairly long time with as close as possible to only bug fixes as changes. And that's 100% valid in its own context. Guix apparently prefers rolling release. That's also 100% valid in its own context. But those two contexts don't mix well, through no fault of either party.

> although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place,

While I also see the appeal to going pure guix, the cross pollination is good for both projects, especially (IMHO) guix. This provided a gentler on-ramp to using guix at a smaller scale without the flying leap that is switching distros outright, and (per the article) the Debian maintainer(s?) have found reproducibility problems while doing their work which is quite valuable to guix.

> OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.

Subhurds are really cool, but I would argue there are lots of practical uses that don't really need to go that far.