The issue is about the OOXML elements in section 2.15 of the OOXML specs. This section describes compatibility items for documents created in the past with older office versions or even with WordPerfect. The tags should only exist in converted legacy documents and should not be used in any new documents.
The first thing to say is that OOXML does not require any implementation to support these tags. There is little reason to support these tags for virtually any application.
Secondly, IBM's Rob Weir argues that "these legacy tags are some of the most important ones in the specification". Of course he would because he wants to OOXML to look bad. The fact is that applications like OpenOffice currently manage fine in converting most .doc files without supporting these compatibility features If implementing the compatibility tags is really so important then people could interprete Rob's statement that you should never use an implementation that doesn't support full compatibility features with legacy documents and stay with what you have.
Thirdly, the compatibility tags are about rendering Office documents. Rendering behaviour is described in OOXML (or ODF for that matter). It would be very strange to exactly describe how the compatibility tags rendering would have to be, while the normal rendering is not described. Office document rendering is always implementation specific.
Fourthly, these tags describe that converted documents may have rendered differently when they were originally created in their original application. Even for applications that are not interested in recreating that actual rendering behaviour these tags can be valuable. When opening a file and parsing these tags an implementing application can give the user a warning that the document looked different in it's original form. This could be important for evaluating conversions of documents that may require very faithful representations like notary documents or documents that archive printed works.
Ah, but ODF does not have this legacy compatibility shit. Why put it into a standard ? ODf has chosen a different approach for dealing with legacy compatibility. It just doesn't define it but leave it implementation specific.
For instance OpenOffice uses custom application settings like:
If Microsoft would use ODF then they can use the "Application settings" to create fully standard compliant documents and still make them impossible to be interoperable. At least in OOXML the extend of the compatibility is known and when a compatibility issue is found it can be recognized and the uses warned accordingly. In ODF files when using the "Application settings" for compatibility the only thing you can do is to warn the user that the document can behave differently because it has separate undefined settings for different applications.
Two solutions for ugly old settings. Both can lead to very ugly documents. But at least the OOXML stuff is only for the past, the ODF "application settings" can keep haunting us for a long time to come...