A lot of comments resolution would not nescesarily mean a lot of change in implementations.

Actually, a large amount of the technical comments submitted in this case do require substantial changes to the implementation. Even if 90% or more of the comments were editorial or otherwise easy to fix, remember that there are in fact thousands of comments, so hundreds of them will not be so easy to fix.

The big question is: will MS show the courage to make any significant changes to the Office file format, like dropping the deprecated beast VML? VML is not really used for much, and it is not really needed, but eliminating it would mean some coding effort, not just a quick fix. VML as a deprecated but required alternative to DrawingML is one of the big barriers to entry for independent implementations of OOXML. (There are more, but that is one of them.)

In the Ecma suggestions for instance:

• Expand the support for available Object linking technologies to include Object linking technologies from other platforms as well
• ST_Lang and ST_TextLanguageID should be changed to specify that the conventions defined in IETF BCP 47 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) are to be used. In addition, ST_LangCode should be removed
• Support IRIs (with non-ascii characters) for part names in the OPC at the logical level

Certainly the changes in OOXML will lead to some XML schema changes. That will take altering of MS Office 2007 no matter what so adding some improvemts will not be much of a problem.

Also 90% of comments of the national bodies are either editorial of obvious format spec bugs that would not require any changes to MS office (or any other implementation) itself. A lot of comments resolution would not nescesarily mean a lot of change in implementations.

Where in this case Microsoft trough Ecma would be very stubborn is likely to be in area's of legacy compatibility. This is a strong issue for them and comments that suggest dropping or diminishing legacy compatibility are not likely to get resolved.
this seems the area where the national bodies might not agree with Ecma / Microsoft

If nothing can change in the existing software, then I see only two options: either Office 2007, currently the only producer implementation, will not adhere to the updated standard, or no comments will be addressed and everything is kept exactly as in ECMA-376. Judging from the extensive criticism against DIS 29500 even from many "yes" voters, it seems highly unlikely that it will pass in February if changes are restricted to fixing typos and clarifying the description of a still-broken format.

This reminds me of an exchange of email during the efforts by Microsoft to standardize the file sharing protocol that Samba implements (CIFS). After a white paper was published demonstrating a man-in-the-middle security attack against the current protocol Microsoft responded by publishing a specification for cryptographically signing the packet exchange. This change fixed the security hole and was a good first response to the attack. Unfortunately, after analysis by some of the experts on the list we discovered that there were some theoretical holes to the new signing protocol, which needed a few trivial changes in order to fix and improve the security. After these proposals were submitted, the response came back from Microsoft that although the fixes were valid, unfortunately the code was already written and was going to be shipped in the next service pack. End of discussion. It wasn't even in a shipping product yet, but the specification was determined to be unchangeable as they didn't want to change their existing code.

Let's bet on the fact that Microsoft/ECMA will propose changes that will look like this:

We don't correct the NetworkDays() function in order to add support for Muslim countries, but we flag it as deprecrated, and we create another one named NetworkDays2() that has the support for this feature. The right thing would be to correct the function, not to create a new one. I take the bets on this one.