A few days ago (on the 25th), I finally added the alternatives framework to pkgsrc; haven't had a chance to write about it until now.
The actual implementation is very different from what I had in mind when I started. It is composed of an independent utility, pkg_alternatives, and a make module, alternatives.mk. The later accomplishes perfect integration of the former with pkgsrc, so that the use of alternatives during package development is as painless as possible.
First of all, and as I already discussed, this implementation uses wrappers in favor of symbolic links for better flexibility (specially across NFS-mounted trees).
WRT its use during development, the package author only has to create an additional file, namely ALTERNATIVES, which is automatically read during installation. Each line of this file is fed to the "pkg_alternatives -w register" command to add the given wrapper/alternative pair to the database. There is no need to define any special variable.
Furthermore, the pkg_alternatives utility has been reworked to support two modes of operation: the group (AKA package) mode and the wrapper mode. The former operates on a whole set of wrappers; each set is identified by the package name that created it. The later operates on independent wrappers, and can be used by the user to tune each wrapper to suit his needs.
At last, the alternatives framework has been made completely optional due to lots of complaints (and they were right). It will only be activated when the administrator explicitly installs the pkg_alternatives package. Otherwise, no wrappers will be created anywhere. And all of this is binary package friendly, of course.
At the moment, only vim and nvi have been converted to use this system. I will commit updates for both the Python and Java packages very soon, as there has been no more negative feedback.
Hope this makes pkgsrc a bit more powerful, specially when used on extremely reduced Linux distributions :-)