There is a big difference between a standard and an implementation. If you only have one implementation (webkit), then developers will start being lazy and depending on certain quirks of that implementation. You reach a point where these quirks can't be changed, otherwise half the internet will stop working. Having multiple rendering engines means these quirks are more likely to be fixed, and not relied upon. It's also impossible to say if webkit will still be the dominant engine in 5-10 years.

For the same reason, this also leads to degradation, and slows down the evolution of the engine. A good example is gcc vs clang. For years gcc was the compiler for *nix, then clang comes along. This led to a new found enthusiasm to make parts of gcc better. The same happened for firefox when chrome came along. and works the other way. We even have half-decent IE releases now.

Doing this would mean being forever stuck in single-threaded land for rendering (e.g. nothing like Mozilla's Servo project could ever happen).

People have tried to parallelize WebKit and failed: too entangled, too much code making too many assumptions... Parallelism is one of those things that's just incredibly hard to bolt on after the fact.

So if you want browsers to never really scale well to large number of cores, by all means try to get them to all switch to WebKit.

Are you implying Presto is multi-threaded?

No (though it will in fact do layout in parallel with JS execution by time-slicing its JS, last I checked, unlike other UAs).

My point is that it's bad if all browsers switch to WebKit and web sites absolutely require WebKit to work correctly, which is what the parent of my comment was suggesting should happen. This point is somewhat independent of what happens with Presto per se.

That's not how it works in reality. IndexedDB has been in WebKit for a couple of years now but Safari still doesn't have it.

It's not as if the browser vendors simply do a 'git pull && make' every couple of weeks.

IndexedDb is a proposal and it doesn't affect rendering.

But your point is taken.

...until differences in ideas about how a rendering engine /should/ work came up and webkit is forked.

That's not really a problem. Experimenting by forking the dominant rendering engine is much more convenient than experimenting by building your own rendering engine from scratch. If your fork has advantages, it's also easier for other people to use your work.

Experience suggests this works for small evolutions, but not more revolutionary changes.

How would that be any different than when IE had 90+% of the user base?

Because in this case it is open? I'm not for having a single implementation but I wouldn't complain if every single browser used the same engine. It still won't be ideal but this by default removes any incompatibilities (assuming the same branch of code is used--a potential problem that will crop up).