It’s worth bearing in mind, though, that we’re talking about “sites (or web apps, or intranets, or whatever) which both (a) trigger IE 7 standards-mode, (b) aren’t actually standards-compliant, and (c) didn’t use conditional comments so will break for IE 8. The proportion of actual real websites that falls into this category rapidly approaches zero, not least because Microsoft went out of their way to tell people exactly—in no uncertain terms—how to fix their sites when IE 7 “broke” them, and everything I’ve seen suggests that compliance with that is widespread.

In other words, the IE 8 “problem”, barring a tiny handful of sites which don’t come anything close to the “1% of the web” Microsoft is scared of breaking, actually only really affects sites accessed from a tightly-controlled environment—either a corporate scenario where IT departments have the final say on what, how and when things get installed, or restricted to specific Windows applications. In both cases, having the IE 7 engine kicking around separately from IE 8 would suffice, without any need for defaults to change or anything like that.

Those who require that kind of closed ecosystem can keep it; meanwhile, the rest of us—those of us who have spent countless days working around IE’s shortfalls—can carry on building standards-compliant sites with one less thing to worry about, and all those quirks mode sites out there will continue unhindered anyway.

It’s not just “breaking the corporate intranets” they’re worried about. There’s a metric bucket-load of software out there that embeds the IE browser control and then fires it’s own hard-coded shonky HTML in there. What happens when the underlying rendering engine changes? Yep, that’s right, the application breaks. It’s a difficult one.

Of course, to do so would be to admit that IE isn’t nearly so much of a critical embedded OS component as was stated in anti-trust trials, even though we all know that to be bunkum—but to admit it officially would be tantamount to perjury.