Edward Diener made the observation (emphasis is mine):

• I would much rather the syntax remained as consistent with C++ as possible and the places where CLI diverged from C++ occur because GC types are different than C++ types in that they are automatically garbage collected, be the primary focus of a programmer's understanding.

In my previous blog entry, I listed two reasons not to conflate the type category with where objects of that type can be allocated, namely to let us in the future support allocating native types on the GC heap, and CLI types on the native heap. The decision to garbage-collect or not should not be per-type (as it was in MC++), but per-object.

To that, I should also add that "CLI types" already does not mean "garbage-collected types." In particular, the CLI knows about two kinds of types: reference types, and value types. First, value types are never garbage-collected in their unboxed form. Second, nearly all programs have objects of reference and boxed value type that are intentionally never collected because they are used right through to the termination of the program; they are one reason why the CLI GC is generational, and why the CLI has features for controlling whether or not such objects ever get the finalizers run, for example.

• Now C++ programmers must use a new syntax, '^' and '%', where they are already use to pointer and reference syntax. This only creates more headaches for C++ programmers using CLI.

That's possible, but in our experience so far (having tried to do it that way for two releases now) we've found that users are far more apt to be confused by failing to surface an important distinction. This is the balancing act of language design: it is just as bad to fail to surface an important distinction (which creates a trap and a usability barrier) as it is to needlessly surface a distinction that could have been hidden from the programmer (which creates clutter and a different kind of usability barrier).