Now that the build scripts have been reimplemented, deployed on a new hardware and with a new sysadmin), this finally sounds doable to me without the need for any additional virtual machines for the build slaves.
Ryan's idea was to automatically upload archives of +universal ports only when a package like wine asks for i386 or universal. In fact this is already working, so the ticket about "building +universal" could be closed as fixed as far as I'm concerned.
I'm not sure what the situation is with VirtualBox. Has i386 been "disabled" just because it was annoying to compile all the dependencies from source? If that's the case, the universal builds could probably be enabled again.
Some additional builds of +universal build tools (ld, clang++, ...) might be handy for older OSes (10.5 in particular; but we currently don't provide that one).
We could in principle build all the ports as +universal with a few additional lines of code (and by consuming approximately three times the resources we currently do), but maybe we should go with the current approach for now and see whether there is any need to add additional candidates for universal builds later on.
As far as +quartz is concerned: I started implementing preliminary support to build with additional variants. I will need some help extending the script that is currently responsible for installing dependencies (portname +quartz usually needs different dependencies than portname +x11), but once that gets fixed, it would enable manual builds with arbitrary variants for now (which we shouldn't start misusing).
Once that is in place, we could start implementing some heuristics to determine when to build a port with additional variants (either some hardcoded list of ports or all ports that provide a non-default +quartz variant etc.). The nice thing about the current buildbot setup is that we don't need any additional resources (other than some extra disk space and CPU clocks on existing infrastructure) to achieve that.
See also #51995.
