First of all, there is a new compiler conditional, disabled in XE3, which is named AUTOREFCOUNT.
See for instance this official XE3 documentation article.

Then, there are some attributes: [Weak] [UnSafe] [Ref] and their corresponding types in system.pas: WeakAttribute UnsafeAttribute RefAttribute.
A WEAKREF conditional sounds associated to those.

And some new low-level functions, which try to implement some weak-reference system with Zeroing, just like we did for mORMot - and for Delphi 6 and up. ;)
Main implementation difference is that we maintain a per-class hashed list, whereas the XE3 version is global, and obviously not yet profiled for speed (there is a giant lock for the whole application, using TMonitor - not the best scaling method I know).

The link between compiler and RTL sounds already possible, even if not enabled:

  • Some [Weak] references appear in some places in the XE3 code (e.g. in classes.pas e.g. for TComponent.FOwner);
  • Some low-level functions like InitializeArray and FinalizeArray (called not only for arrays) check if type information equals nil for any field, and in this case, handle it as a weak reference (via the new _ClosureRemoveWeakRef low-level function).

I was not able to see a difference between a weak reference and a zeroing weak reference, like what we did for mORMot.
Most of the time, a weak reference is enough. Zeroing weak references are safer, but also much slower, even if you manage a huge number of instances in such a global locked list.

As a quick conclusion, we may say that Embarcadero future for Delphi is to embrace the ARC model used by Apple, including zeroing weak pointers.
It is IMHO a better solution than a garbage-collector based memory model for an unmanaged environment like Delphi.

But one issue of the implementation as previewed from XE3 sources (in addition to its alpha stage and poor performance) is that it is global to the application: the TObject memory model will be either ARC-based or manually handled (just like before).
This is a breaking change in the Delphi way of coding, and I would rather prefer a dedicated TObject / class type, able to coexist with the huge amount of third-party source code. Even if most user-level code may work with no issue (since Free will use the reference counting), some lower level code may be broken by such a change.
A dedicated class type may allow clear distinction between the "classic" model expecting manual Free of instances, and the new ARC model with its own style of coding.

I like very much the FreePascal approach, with its syntax modes: you can have several syntax and even class models in the same application. It is used for instance to mix objective pascal and classic pascal classes in the same project. Clean and easy.
It will also make the OS X integration much easier than the current interface-based marshalling of the Objective C APIs within Delphi. A lot of plumbing which should be leverage at compiler level.
I hope Embarcadero has such features on the road map, otherwise its future could be problematic: not compatible with legacy code (which is its main strength), and with no obvious benefit when compared to alternatives.

Feedback and comments are welcome on our forum, as usual.