Fourth

Sure, if it's actually broken, that either means it wasn't tested or some higher-up made the decision that it wsn't worth the time investment to support FF. But...

> Not much Firefox can really do about that other than making Firefox just another reskin of Chromium.

This isn't really true, and all the talk about being "bug compatible" with Chrome really misses the mark. The principal thing they could do is *fix the known bugs*. Updates to web specs, especially CSS, commonly add new features that developers have been crying out for for years, and when they finally become available, people have been waiting patiently for years and really want to start using them.

FF is often the last to implement new features, eg :has() which is probably the greatest CSS improvement since its inception, and where FF lagged by years. When it does get new features, they often have trailing bugs that can take a long time to get fixed, eg https://bugzilla.mozilla.org/show_bug.cgi?id=1882408 .

I know I've personally had several occasions where I was about to submit some new frontend updates, did a final round of cross browser testing, and then get hit with the crushing discovery that something is badly broken in Firefox because of a bug in how it implements some feature that's theoretically been usable for a couple of years. It's true that there are *some* times where it comes down to "there is no single unambiguously correct way to implement this, and FF and Chrome made different choices" (eg the phrasing of the file upload button, which is hardcoded by the browser and which leads to bug reports from Dragon Naturally Speaking users which are unfixable except by giving up and using a fully custom upload control), but those are by far the minority IME.