IE also "improved" rapidly back in the IE4/5/6 days, adding features such as CSS filters and AJAX. These "improvements" were considered much needed progress by developers at the time; later, with the wisdom of hindsight, rightly seen as proprietary extensions with little to no consideration for interoperability.
And if you think the Blink team's membership of, and contributions to, WHATWG/W3C/&c. automatically ticks all the friendly interoperability boxes, you've clearly never encountered monstrosities such as https://compat.spec.whatwg.org/ (created and maintained by Mozilla)
I'm not really sure what you mean when you say "I'm not buying your quick dismissal": I never dismissed anything nor made out either that there is or isn't a large difference between the engines. I just corrected a statement that is definitely factually incorrect (and unfortunately believed by all too many).
On the actual differences between them, Chrome may be "almost identical" to Chromium, but unless you're working for Google, or have very comprehensively disassembled it, the differences is not easy to measure. What could be tiny in binary size could still be a massive change in behaviour, particularly in terms of things like telemetry.
Beyond that, they are of course not equivalent, they're just analogous. Finding a few tiny chinks in the comparison is not the same as invalidating it though. The primary analog is the approach to interop, and the resultant behaviour of the development community. Participation in standards bodies is an improvement over the IE6 days, but if you take a deeper look at Blink development, you quickly realise it's a pretty insignificant one in practice. Google controls the HTML5 spec. (the editor is a Google employee and the WHATWG is not a democratic body like the W3C), and outside of that the Blink team basically just implement what they want and specify later, rather than the reverse. The response of the development community: supporting the monopoly by ignoring interop - is pretty self-evident from links like this one.
My impression is that there aren't any closed-source bits in the browser itself (i.e., there are no proprietary patches to Chromium code), it's just the Google account integration, plus things like Hangouts or Cast or whatever which mostly take the form of extensions, plus things like the Flash plugin.
(Also, that compat page looks very non-monstrous; the vast majority are just aliases for non-webkit-prefixed names, and of the remainder, nothing is anywhere comparable to CSS filters or XHR. Is there a reason this exists for the -webkit prefix but not for the -moz or -ms prefixes?)
This ignores the history of many of these. The webkit-prefixed names came first, and the standardization folks just decided to make the unprefixed forms work the same way. If Chrome implements something as a prefixed property that folks start to use, standardization will be heavily skewed towards their syntax and semantics.
Also, the document does not include some things like -webkit-gradient which Firefox still implements (though I'd like to try and remove it). -webkit-gradient has more features than standardized foo-gradient and causes some complexities in the Firefox code.
(-webkit-gradient wasn't a Chrome thing, however, it was an Apple thing. There's a long and boring history here)
> but not for the -moz or -ms prefixes?
There aren't (m)any webpages out there using moz/ms-prefixed properties that don't use the webkit or standardized versions too. Also, IIRC Firefox and IE stopped prefixing things earlier on (could be wrong here).
I assume because the feeling is that -moz prefixes no longer form part of the "de facto web." Targeting for desktop Chrome isn't as common anymore, but this document seems squarely aimed at the mobile space, where Safari-specific (and to a lesser extent Chrome- and Android-specific) functionality is more or less epidemic.
