What difference does it make and why do it? The UK objections speak to that directly and pointedly, and I hope folks in Massachusetts will read it, so they know what to watch for, if ECMA rubber stamps Microsoft's version of XML with "extensions".
Here's the part, from Section III on what's wrong with having two competing standards:
III. Damaging confusion is already evident
Standard C++ is maintained by WG21, the largest and most active working group in SC22. WG21 meetings, twice a year lasting a week at a time, draw regular attendance by delegates from a number of national bodies and nearly all the important vendors of C++ compilers and libraries, plus a number of people who use the language in their work. By contrast, this Ecma draft was developed by a small handful of people -- awesomely competent ones, undoubtedly, but who do not represent the interests of the broad market of vendors and users.
variant will inevitably grow wider over time. The document proposes no mechanism for resolving future differences as these two versions of C++ evolve.
For JTC1 to sanction two standards called C++ for what are really two different languages would cause permanent confusion among employers and working programmers.
There is clear evidence that this confusion already exists now, even though C++/CLI has only recently been adopted as an Ecma standard and is commercially available from only one source.
Currently Microsoft is the only current vendor of a C++/CLI compiler, and also a leading vendor of a Standard C++ compiler. And yet Microsoft’s online documentation consistently confuses the syntax and semantics of C++/CLI with those of Standard C++.
Documentation for Microsoft's Visual C++ product contains many code examples identified as "C++" -- not "C++/CLI" or even "C++.Net" -- which will fail to compile in a Standard C++ environment. See, for example, http://msdn.microsoft.com/visualc/default.aspx?pull=/library/enus/dndotnet/html/NetFramework.asp, which has many examples showing parallel code for "C#", "Visual Basic", and "C++" (without the “/CLI” qualifier).
An article on "New C++ Language Features" at http://msdn2.microsoft.com/enus/library/xey702bw.aspx contains this paragraph:
"The following table lists new keywords that have been added to the C++ language. Note that some keywords consist of two words separated by white space." The page goes on to list what are officially context dependent identifiers, but it refers to them baldly as new keywords also, ignoring the subtle difference buried in the draft standard.
Note the statement that keywords have been "added to the C++ language" (no mention that it only applies to this new variant). There is no indication that using any of these new keywords renders code completely non-portable to other environments. Further pages with information on single keywords leave an even stronger impression that C++ is the language under discussion, not the C++/CLI extensions to it:
These pages consistently fail to distinguish clearly between Standard C++ syntax and extensions/adaptations for the CLI environment. Microsoft is not the only source of articles in which C++ and C++/CLI are considered equivalent, but they invented this new language and if they cannot tell them apart, it does not create confidence that average programmers will be able to maintain a clear idea of the many differences between them.
Possibly the largest faction of C++ programmers in the world are working mainly with Microsoft’s compiler and platform. To them, Standard C++ is what Visual C++ does. If they develop expectations that “C++” now has these new features, whether or not those expectations are accurate, it will place at a disadvantage all competing products which offer conformance merely with Standard C++. Portable programs will be disparaged for not taking advantage of platform-specific extensions available only in the Windows environment. (There is an open source implementation of CLI for other systems, called Mono, but to our knowledge currently no other compiler in the market supports C++/CLI.) The objective of using Standard C++ to achieve portable programs will be completely undermined.
Ah! "It will place at a disadvantage all competing products which offer conformance merely with Standard C++"... The last two paragraphs are interesting too:
OK. No plot. Well. Shall we just call it a pattern, then? Dear Massachusetts, please notice what the tech community is trying to tell you. One can learn a lot from patterns.