You really want to download and read http://www.gotw.ca/publications/C++CLIRationale.pdf. It's 54 pages (just under 2 MB) of WHY the C++/CLI product is the way it is. Why isn't it a library? (Because the compiler really needs to be in on what you're doing to hook in the runtime support properly.) Why doesn't it use underscores? (Because programmers hated them.) You don't have to be a compiler-writer to follow the rationales laid out here. It provides some interesting insight into the way the standards process works and the way that decisions get made by a team or by one person who is strongly committed to "doing it right this time." However this is no dry committee report or academic paper: you will find the word "I" throughout the paper, along with anecdotes about conversations, code written out quickly to help guide a decision, and other vignettes that make this must reading for all we C++ people.

Some quotes (words outside "" or in [] are mine, not Herb's):

• "Many C++ programmers tried hard to use [Managed Extensions], and most failed."
• Mapping destructors to dispose bidirectionally (probably my favourite C++/CLI feature) was "nontrivial, and required C++/CLI to influence CLI to modify and regularize its pattern)."
• "There comes a point where you have to admit that you’re trying too hard." (On having a class that inherits from System::Object magically be a ref class without having to use the keyword, an idea that wouldn't have been good anyway since it would have ruled out mixed types.) 
• "Having private as a default matters so much that Stroustrup correctly felt it was worth the high cost of taking a new keyword just to have a category of user-defined types where the default was private." (In a section drawing parallels between some C++/CLI decisions and the decades-old decision to add class to a language that already had struct.)
• "...in the C++/CLI design effort, some people tried hard to leave open the possibility of allocating C++ objects physically on the CLI heap; that is impossible in general, and trying to persist in this led to confusions in the type system that have now been avoided and removed." (Ouch!)
• "As for whether this set of extensions amounts to a different superset language, a compatible dialect, and/or a binding: I think you can find reasonable people who view it any of those ways. Whichever noun you prefer, it is the most compatible set of extensions I know of to any programming language, standard or otherwise, including for nearly all macro cases — which are notoriously next to impossible to support in a compatible way. Achieving that required putting requirements in C++/CLI that placed a greater burden on compiler writers in favor of preserving strong ISO C++ compatibility and avoiding conflict with C++0x evolution, and improving programmer usability so that programmers would use the feature instead of switch to another language (unlike with the Managed Extensions). These choices reflect the designers’ great respect for ISO C++."

The paper closes with an FAQ that includes questions I can only describe as rude. I am guessing that Herb has been patiently answering these in email and at meetings for many years now.

If you still aren't really clear on WHAT the C++/CLI version of C++ is, what happened to the underscores, or how C++ can be the best .NET language of all (offering features C# and VB just cannot offer) then this paper might not be the place to start, since it's not a syntax review or a tutorial. But then again, maybe understanding the WHY will motivate you to go and learn the WHAT.  And if you want more WHY, the paper is liberally sprinkled with links to blog entries by Herb and Brandon (mostly in 2003) with even more details.

Go! Read it, now!

Kate