Some notes:

• The above result is with a single render command, using three render-layers and a composite.
• The new 'only render z values in this layer' works for solid faces only. You can use the actual model you want to mask, or any other mask plane.
• It is also possible to isolate pixels behind the ZMask instead of in front, with the Negative option.
• Here's a blend file for testing.

The zmask render-layer option also allows to do more complex masking... it can even include the object itself in the mask, or solid objects in front of the zmask. Below images illustrate this.

Previously when duplicating objects with dupliverts, duplifaces, dupligroups or particles, the data of these objects was stored once for each object by the render engine. Now it will be stored this data only once, which means that rendering such objects now is much more memory efficient. This made it possible for example to render many tree leaves in Peach.

Note that with either radiosity or raytracing still do not fully supporting instancing, which means that for these features memory usage may still be high.

Also, the render engine now clips objects by their bounding box for rasterization to improve performance.

When the Blender render pipeline was redesigned - for Elephants Dream in 2006 - one of the unresolved specifications was to tackle the artefacts you get in anti-aliased polygon edges when you use high dynamic range color (colors beyond the 0.0-1.0 visible range), or when you do color correction or remapping. Not to mention that while compositing, you actually want to get the same quality anti-aliasing for zbuffers, id masks, etc.

Analyzing this problem resulted in only one possible quality solution: a composite should never happen on anti-aliased images, but instead be done on all raw samples as they come from the renderer, which then as a last step maps it all to the visible 0-1 range, and then combines the samples to an anti-aliased result.
In other programs this is being achieved by just rendering 2 or 4 times larger, do the compositing and then scale it down. In Blender we use the more advanced 'distributed jittered sampling', which actually already renders 8 complete images (for "OSA 8"). It's just a matter of saving all those images on disk, then after render read it back, and do the composite.

Or to summarize, this is the FSA pipeline:

Render -> save all samples -> composite -> map to visible range -> filter-combine samples

Whilst previously OSA did:

Render -> filter-combine samples -> composite -> map to visible range

The key benefits of FSA 

1. Dynamic range renders
   When you use lamps or textures that have colors beyond the standard 0-1 range, you can use the compositor to adjust this and map to a visible range. Only after all compositing and remapping, the anti-aliased filtering and sample merging happens.
   Even without compositing, FSA will in this case benefit a rendering as well.
2. Solve AA issues caused by solid - ztransp - strand combining
   Blender renders solid, ztransp and strands in seperate 'layers', combining it with alpha-over functions. By anti-aliasing such layers first, and then combining them, you can get artefacts (looks as if the background peeks through the anti-aliasing). FSA efficiently solves this.
3. Allow color/contrast/brightness mapping.
   Whatever you do in a composite, even make it 2 color black & white, by having these operations done on the raw samples, the end result will always look correctly anti-aliased.
4. Use passes with full anti-aliasing
   Passes like zbuffers, id-masks, motion vectors, normals... these don't anti-alias well, and work much better when you can apply them directly on the samples before merging it all into the final image.

Memory usage and overhead

FSA makes use of Blender's efficient tile-based pipeline, so you won't need much more memory for renders to use it. There's a couple of considerations to make though.

• For each tile rendered, FSA allocates layer/pass buffers for each sample.
  Example: for a 2k render, 8 samples, using 4 x 4 parts, it means that per tile 8 x 128k pixels have to be stored.
• Therefore it's a good convention to make tiles smaller, especially when rendering in threads (each thread allocates for each tile).
• However, after a tile render is finished, it saves the entire result to disk, using the 'save buffers' convention. So by rendering tiles smaller, you can compensate for the FSA overhead quite efficiently.
• The render time overhead for FSA is a constant. Only the overhead of allocation, writing in buffers, and saving them is added to the render times, disregarding scene complexity or render features.
• Compositing overhead is also a constant, but here the most time gets "lost"... since for each sample a full composite happens. We'll be looking at smarter threading for compositing to overcome this.

(Cool images follow!)

Read about adding statistics in rendered images here.