Jared J and I looked at this bug a few months ago and had a bit of correspondence with Alex about it. This problem is a little bit more generic than the original summary and description alluded to. In fact, in IE, if you perform an XHR request with handleAs set to XML and the server sends back any XML-based mimetype that IE does not understand, this fails.
With some deliberation, Jared and I created the attached patch. This patch is actually more generic than the existing code. Rather than checking that the request was performed using file:/// as is done currently, the response is inspected to ensure the documentElement value is set. If not, the request needs to be re-parsed using the XML handlers available to IE. This patch fixes the described behavior, addresses a current solution, and decreases the size of core by a few characters.
I figure this issue is relatively important, as it may occur to any user who wants to use a specification such as Atom, which prescribes sending a feed using a mimetype of application/atom+xml.