Microsoft's C++/CLI Language Specification is an ECMA Standard (ECMA-372) and they are trying to fast track this document to be an ISO standard. The problem is that the language specified is very different from C++ and so is likely to create a great deal of confusion. Details can be found in the UK objections, which suggest that a name distinct from C++ be used for the proposed language.

The UK objections Summary:

In response to document ISO/IEC JTC1 N8037, the UK objects to Fast Track Ballot ECMA-372 1st Edition C++/CLI Language Specification, on the grounds that there is a contradiction with an existing JTC1 standard. ISO/IEC 14882:2003 is the standard for the C++ programming language. Adopting a second standard under the proposed name of C++/CLI will cause unnecessary and harmful confusion in the marketplace.

We consider that C++/CLI is a new language with idioms and usage distinct from C++. Confusion between C++ and C++/CLI is already occurring and is damaging to both vendors and consumers.

A new language needs a new name. We therefore request that Ecma withdraw this document from fast-track voting and if they must re-submit it, do so under a name which will not conflict with Standard C++.

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:

The UK request that Ecma withdraw this document from fast-track voting and if they must re-submit it to JTC1, do so under a name which does not include “C++”.

This paper should not in any way be taken as suggesting that there is a sinister plot by Microsoft or anyone else to usurp or subvert the C++ Standard. Microsoft is an active participant in and a strong contributor to WG21. We accept that the people involved in this project are sincere in what they are trying to accomplish and do have persuasive (to them) reasons why they think these are good ideas. However, we also think they misunderstand what is important to other people.

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.