> Sure, but that "backup plan" wouldn't be another similar engine codebase, like Trident or Gecko. I can't fathom any future technical case where those would do

> Sure, but that "backup plan" wouldn't be another similar engine codebase, like Trident or Gecko. I can't fathom any future technical case where those would do but Webkit would not. Certainly, any situation that made Webkit unviable would probably affect Trident or Gecko or Presto the same way. It's not that we specifically need to preserve some other code-base so that we can bust it out if something happens to Webkit, it's that we need to make sure that it's possible for new rendering engines to spring up and keep applying the pressure of competition. > Because today, if you come up with some "completely different engine", in order to "achieve compatibility with existing sites" you would not just have to "mimic all the weird bugs and corner-cases of Webkit" but also those of the other major engines. If the majority of sites each only worked in one major browser, or if they served completely independent markup to each browser, then yes, you'd have to reverse-engineer them all to obtain decent compatibility. However, that's not the case these days - the vast majority of sites stick to the parts of the Web platform that are reliably, consistently, interoperably implemented across the major browsers. If something has been implemented correctly four times, even if it took a while to reach that milestone, it's much, much, much more likely that it can be implemented a fifth time, than some feature that has exactly one implementation and it's not clear which behaviours are intentional, which behaviours are accidents, and whether the accidents must be preserved for compatibility reasons.