When talking about Delphi for .NET (the language, not the IDE) there are quite a few misunderstandings. The IDE doesn't support the latest features of the .NET platform, but what was done for .NET 1.1 is actually quite nice. It is true that Delphi provides extra non-CLS-compliants features you should avoid to use in cross-language projects. But cutting class references, virtual constructors, or named constructors from the language (just to name some these non-compliant features) would have been a mistake. Delphi is Delphi and should remain Delphi whatever the platform.
On this, I fully agree with Craig Stuntz: "Folks, C# exists, and it's a fine language, so if you want to use something which behaves exactly like C# why not just use it? C++/CLI and Delphi for .NET aren't supposed to act precisely like C# in every way because they're different languages."
Craig makes this comment after referring to a blog post by Steve Teixeira, longtime Delphi guru now working for Microsoft. Steve, who is Visual C++ product manager, tells the same about managed C++: it doesn't need to clone C# feature by feature... He also underlines that there is no formal definition of "first class .NET language"... so telling if a language complies is very subjective.
There other two interesting elements in the post. First, it comes clear that for Microsoft making their compiler adhere to the C++ standard is not very relevant. Expected, but odd. Second, some of the discussion echoes what's debated in the Delphi community: Microsoft tries to add the latest .NET features to C++, while users claim they use it mostly for non-managed projects. The similarity ends here. In fact, differently from C++, Delphi for .NET genaretes fully managed code which is backward compatible with the Win32 counterpart, something you can hardly obtain with MSFT tools and a very good reason for Borland to keep investing on the .NET side of Delphi.
Finally, on a related issue that was surfaced in the newsgroups, Nick and Rudy clear out some of the myths surrounding namespaces in Delphi. I already said many times I do like the Delphi implementation, which let's you tackle a new problem without changing the way you write the code. It is true that the same "uses" statement means slightly different things in Delphi Win32 and Delphi .NET, but the same could be said for the Free call, TObject, and many other elements of the language. Again, I really like the way it is.