Earlier quoted context omitted.
> root cause is that Chromium is well suited to being embedded Bingo. Let's not forget, Chromium itself is built off a fork of kHTML, the rendering-engine-as-a-library originally developed and used by KDE project. Apple forked kHTML and released WebKit. That gave the world Safari. Not long after, WebKit became the engine powering Chromium/Chrome, but with process isolation and high-octane JavaScript interpreter (V8).…
> Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink. I see you've bought into Google's historical revisionism. When Google introduced multi-process rendering into Chrome, it was a massive technical innovation, but it was built at such a low level that it was effectively proprietary to Chrome. No one else could use it without pretty much adopting al…
This is a bit of a silly narrative built on what's basically different architectural decisions. Chrome embedding was intended to be through CEF (which was fully multi-process), while WebKit through WebCore.
You could just as easily say that Apple decided not to do the hard work of migrating Chrome's multi-process architecture into WebKit and instead made a hard break and just started landing incompatible changes. From the thread you posted, you can even see a WebKit embedder at KDE blindsided by the news[1].
But in reality, browsers are hard, and in a way WebKit and Chrome were always forks but with shared components. The Blink fork was just a fork of one of the biggest of those components and a formalization of what was pretty much always the case by moving to separate source control, code review, etc.
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...