Your proposed approach of always shipping all the rendering engines you have ever had is exactly what IE is doing. This has two drawbacks: 1) It makes your a

Your proposed approach of always shipping all the rendering engines you have ever had is exactly what IE is doing. This has two drawbacks: 1) It makes your app huge (because you have to support many wildly different modes, some of which have different architecture requirement). Clearly less of a problem if your app comes preinstalled with the OS anyway. 2) If everyone were to adopt it, it significantly raises the bar for a new entrant into the browser market: instead of just implementing the specs, it would have to reverse-engineer a bunch of legacy modes. This is actively bad for the web, and a major reason why Gecko, WebKit, and Presto are NOT taking this approach. For the rest, I understand the situation you're in, and it's unfortunate. But your claims about how browsers _should_ be architected assume that things like the web's security model or the general feature set browsers need to support are somewhat static. They're not, and changes to them can require significant architecture changes. Basic things like the in-memory representation of the DOM are being actively changed in WebKit and Gecko every so often, as new requirements come up; I can't speak to Presto and Trident because I can't see the code. Which means that porting security fixes becomed pretty difficult, because your APIs in the old release are different, your code flow in the old release is different, and most importantly the invariants the old release maintains are different, because the specs that determine those invariants have changed in the interim.