So with all this talk about smart pointers, I guess you are agin garbage collection? OK, I admit it. Garbage collection is in general a great liberating thing. But I don't think it is right for native Delphi.
Delphi Object Pascal is surely supposed to be a 'as close to the metal as is sensible without being rust' sort of language. This is what differentiates it from C# and Java, which emphasise portability and safety, but run in vast, cosy-but-stifling, virtual machines that arrive (in one case) as gargantuan downloads and (in the other) seem to need updating every 10 minutes. When you do garbage collection, you are handing off a piece of control that by rights belongs to the obsessed, micro-optimising programmer. This is not the Delphi way.
Remember: we already got some Pascal garbage collection in Delphi.NET - and that didn't work out brilliantly, did it? Also, if we get GC in native New Delphi, will it not introduce hideous data sharing problems with Olde Delf modules, like managed and unmanaged code in Visual C++?
On the other hand, the smart pointer design I cited back there was the work of one Barry Kelly. Mr Kelly is one of the doubtless vast team that CodeGear has assembled to work on the compiler, and he seems to be pro garbage collection (and points out, amusingly, that Jeff 'Coding Horror' Atwood apparently believes that stack-allocated items are garbage-collected), although we cannot know what he thinks in this specific case.
Mr Kelly is rather well placed to have an opinion on this matter; if he were to produce it and it ran contrary to mine, I would be happy to consider it seriously. I am sure he is very relieved to hear that.
In real life, the issue of memory management does not arise as much as you'd expect in practical Delphi code, because of the ownership system in the VCL framework.
Ah yes - what about the VCL? Ok, not actually a compiler issue per se, but in Delphi the twain are intertwined.
The VCL was a miracle of its time. It was eight trillion times better than MFC. It got things right about delegation and event handling and resource storage and organisation that are still regularly being got wrong. The VCL hierarchy is perhaps a little deeper than is fashionable nowadays... but so what? The thing works, and works a treat.
You will recall the design principle called 'separation of concerns', which says it is a good idea to minimise dependencies between different functions of your program. The VCL doesn't really 'do' separation of concerns. Its leanings are more towards consolidation of concerns into one honking big woe.
The solution to this, it seems to me, needn't be painful. The VCL is an excellent tool for implementing the 'V' part of the 'Model-View-Controller' pattern, and should be left alone.
All that is needed is a new, separate library to do the concern separating. And there is already an extremely elegant, compact and multi-lingual open source library called PureMVC. Although initially targeted at ActionScript and Flex, it already supports a dozen or so languages and platforms. I see no technical reason why New Object Pascal could not be added to the tally.
Among other advantages, it would mean that if CodeGear were to create a Delphi cross-compiler for, say, the Palm Pre, then they would not need to port the VCL at the same time (a highly desirable outcome in view of the Kylix and Delphi.NET fiascos, where many dollars were spent creating unsatisfactory re-implementations of the VCL). CodeGear could create a new front-end library specifically appropriate to the Pre device, and not backwards-compatible with anything, and they would be done.
Sure, users would have to rewrite the front-ends of their MVC structured programs - but realistically they would have to do that in any case, because a PC UI does not work well on a smartphone (don't believe me? Ask a Windows Mobile user). Everybody would be happy.