No: it's in the current version. I don't work on "undercover" development. Whatever you see on my web pages can be done with the current version. The round bond pads were done with the "polygon" command, using a Tcl script which I can post if you like. The 45-degree traces were done with the "wire segment" command. Be warned, though, that 45-degree traces are not especially compatible with the corner-stitched tile database. They tend to fracture up the tile plane into thousands of pieces. I recommend generating each one in its own subcell to keep it from interacting badly with everything around it. Again, using a Tcl script helps a lot.
Additional note: Revision 7.5.82 implements the gds merge true option. Although the algorithm is a bit slow, it generates multi-segment polygons in GDS output, producing GDS files that are much more compact and avoiding the main complication of having a fractured tile plane produced by tile-splitting non-Manhattan geometry. The resulting files are generally much more compatible when exported to other EDA tools.
I have done schematic-driven standard cell layout with Magic and XCircuit, but I have not specifically worked on a schematic-driven flow otherwise. I have also used TimberWolf to optimize placement in non-standard-cell layouts, using more or less the same flow, but again, it pales in comparison to what you would normally refer to as schematic-driven layout.2) What would be used for parameterized device generation? Would this be through scripting or are other means supported as well? Is there any conversion tool available for P-cells (to Magic-format)?
There is a little-known set of support tools for generating parameterized devices in Magic. Unfortunately, the burden of development is on the end-user and not the foundry. On startup, magic loads a Tcl script called "toolkit.tcl". If you look at this file (/usr/local/lib/magic/tcl/toolkit.tcl), it gives some guidance on writing Tcl-based parameterized cells. I have some example test toolkits that I can provide to anyone who is interested in developing one. There is no conversion script for P-cells.3) Magic has some special ways of representing data (abstract layers, etc.). Does this significantly restrict compatibility with commercial tools such as Cadence?
Magic does not necessarily have to represent data by abstract layers. The most significant restriction is due to the fundamental database representation, which in Magic is tiles on a plane, and in most other CAD tools is based on objects. In particular, this makes it difficult to represent polygons and paths in Magic as independent objects. I have only minor difficulties moving layout back and forth between Cadence and Magic. P-cells are difficult to preserve through the transformation, but it can be done. I use Magic for all of my standard-cell layout, and anything that requires scripting, because SKILL is difficult to program, difficult to read, and Cadence's set of function calls is limited and often just plain broken. Creating layout in Magic and porting it to Cadence is workable, although you end up with things like individual contact cuts where you would prefer a multi-part path object. These problems are less due to the data representation than to the fact that the only common format understood by both programs is GDS (and LEF/DEF), which only understands physical geometry and has no way to handle abstract forms.