How do I bury my head? I’m the one who’s been using it for years and speak from experience. Do you use it? What are your problems with it?

I think we’re misunderstanding eachother. So perhaps consider to outline if you agree with the following:

• uBlue has some systems in place that enable it to detect some breakages.
• uBlue’s pipeline is such to not ship you the detected breakages.
• After a method has been found to fix a breakage (or other issues), uBlue’s maintainers implement these fixes and then, the very next update, the users will receive an image that contains both the updated package and the fixes required for it to not cause problems. Heck, the user didn’t know anything was up in the first place. They didn’t notice a thing*.
• uBlue’s issue/problem detect systems are not absolute; things might slip through.
• However, Nvidia drivers will not cause breakage that will make you shiver in fear.
• uBlue does not fix it on your device. They fix the image and that fixed image will deliver you the fix built-in; so manual intervention are a thing of the past (except for edge cases).
• Their pipeline does not require nor does it detect (through telemetry or whatsoever) the breakage on the device of the user. Heck, as implied earlier, most breakages are detected, prevented from shipping broken, fixed, ship the fixed one before any end user is disturbed by it.
• uBlue is not a Stable system (i.e. it does not freeze packages (apart from security updates) until the next major release). So yes, you receive updates all the time.
• Not being tied to legal restrictions is cool. However, a lot of derivatives do this. So this can’t be its unique selling point.
• uBlue is not entirely free. Its maintainers do pay money for providing some of their services (as has been mentioned by Jorge).
• Some of their images do have testing branch; even Bazzite has.

Ah okay, I see now. Isn’t the term microkernel or something? But yes, I do remember hearing everything was in the kernel for Linux (even prior to this discussion).

It’s not nonsense, just concerns that you don’t seem to have.

There is not one pertinent criticism in there. It’s all meaningless drivel presented as legit concerns.

Which one is a concern you share?

I personally don’t like Manjaro holding out on package updates

Then you don’t use it and that’s fine. The whole point of Manjaro is to mitigate the bleeding edge risk. There’s tons of people who see value in that. Not every distro has to do the exact same thing Arch does. There is something of value in every Arch-derived distro.

• Manjaro repos not being in sync with Arch repos is false and misleading. Arch is the upstream, they’re linked together. Trying to shift the issue into “btw” is stupid. Nobody claims that downstream distros are the same as the upstream, if they were what would be the point. The whole Linux landscape is built around derivate distros. This is entirely in the author’s mind.
• Delaying packages is not stable – that’s not all they do.
• AUR “compatibility” is cited as a problem. For starters it’s a complete red herring – there’s no such thing as “AUR compatibility” and you will be well advised to use AUR very carefully including on Arch proper. But also the author misrepresents how an AUR package can fail on Manjaro. In theory it’s possible that a new feature would be introduced in an upstream package and immediately picked up by a new version of an AUR package, while the new core package is not on the target system yet. But then the author goes on to conclude “the package will break”. Which package? The ones that are already installed won’t break. The new AUR package may not be able to install but that won’t break the existing version. It’s not even certain the new build will fail; it depends on many factors, including how its dependencies are configured and whether it can be built without the new feature. Also this doesn’t necessarily happen on Manjaro alone, it can happen on Arch or any derivate at any time; as long as you don’t update your machine once a minute there will always be a window where AUR doesn’t play well with the core packages that are on the machine at that time. Last but not least, AUR packages are updated fairly slowly and the chances of this scenario occuring with any significant frequency are astronomical; it has never happened to me personally or have ever heard it happening to anybody; but the author makes it seem as if it’s a common issue.
• Security issues. Oh no, a distro has a security issue that has been fixed. Bleh.
• Problems with the Manjaro updater: false.
• SSL certificates for their website expiring. Nobody cares. The user base was not impacted in any way. As a daily user I only found out about it much later, from this kind of discussions. I don’t know what their webmaster was smoking and why they delayed setting up an automatic renewal for so long but it’s irrelevant because it has no relation to the distro or the distro maintainers.
• I’ve explained the AUR “DDoS” in another comment. Briefly, it wasn’t a “DDoS” (obviously) as much as the complete lack of any serious infrastructure behind AUR, which couldn’t cope with its rise in popularity. Manjaro makes it easy to activate and use the AUR. When the problem became apparent it was Manjaro who went out and got a CDN deal and set everything up so that the AUR won’t be in that situation anymore.
• There was another instance that looked like someone maliciously and explicitly hitting the AUR with 10k requests/sec while posing as “pamac”. That one was probably an actual DDoS.