Doing this actually enabled us to remove a special case from our module rendering pipeline. Now there are only two ways MathML modules get served on the web:

With "actual" MathML

Mozilla and IE6 with MathPlayer2 get served MathML markup. Module content is served with the corect mimetype of application/xhtml+xml and the XHTML+MathML DOCTYPE

With "simulated" MathML

All other browsers get served content that has been run through a modified version of David Carlisle's pmathmlcss.xsl transformation that simulates some MathML using CSS and Javascript. It's an ingenious bit of work and has managed to convince several of our users that Safari can actually display MathML. Content served in this way has the mimetype text/html and the XHTML DOCTYPE (yes, yes I know all about the evils of serving XHTML as text/html.)

Previously IE6 was special cased to receive text/xml and David's Universal MathML Stylesheets. We no longer have to do this, IE6 gets MathML if you have MathPlayer2 and doesn't if you don't.

The reason we can do this is because MathPlayer 2 identifies itself to the server in the User Agent string. It would be better if browsers had a way of declaring what namespaces they support. Perhaps in the future we'll see something like this come out of the the Compond Document Formats working group, but in the meantime this is a good solution. Kudos to the folks at Design Science.

Fixing this also had a unexpected side-effect. We've had long-standing bug in Edit-In-Place where IE users who edited MathML modules would not see the MathML displayed correctly when doing a preview. I was able to fix this by copying some of the Math detection smarts into the EIP preview code. All in all it's much easier to use IE with Math Connexions than it used to be.