I believe I have settled on an entirely different preferred solution - multisite.
For my particular situation, my priorities are derived from having to hand over the multiple site setup to another developer (with unknown resource/ability). I believe that with this in mind my question contained a couple of false assumptions, namely
- that a single site would be simpler to hand over to another developer
- that therefore maintenance costs would be lower than retaining multiple sites
The site will probably not have to share much content, and even fewer users, between sites so the main crossover is providing a shared search index. I have already solved this by separating the search functionality via aggregation (in an admittedly circuitous fashion). There are more powerful and efficient multiple site options involving Apache Solr or similar, but having separated search from the sites, these options are still open, and need only be implemented in one place.
A single site with multiple domains must necessarily make use of Domain Access, Spaces, Organic Groups or some combination of these. It may, therefore, be a single site, but it is not a simple site. Even if the documentation I provide with the site is perfect, the inheriting developer may encounter complications or complexities when maintaining or extending this more sophisticated site. Domain Access, though the most popular strategy, worried me particularly because of its interference with the core
I also found this article particularly useful in resolving my indecision. One aspect I had not considered with regard to a multiple domain site was the potential for path conflicts. I can certainly imagine a situation where both site1 and site2 have an /about path, and I cannot imagine an easy, maintainable way of getting round this within a multiple domain site without allowing drupal to create an ugly /about-0 path for site2. I find this distinctly unappealing, and it could cause some issues for existing paths.
I have always been quite reticent about using drupal's inbuilt multisite functionality to share a codebase between different sites (with different databases). For the purposes of updating etc it has often seemed simpler to me just to have separate codebases and manage shared code through version control, (because I can break a single site). In this handover situation, however, I think maybe a single codebase better communicates the absolute similarity of aspects of the different sites. As long as configuration is, as far as possible, captured in Features, there should be little confusion about the degree to which components and behaviours are shared between sites. The multisite codebase can easily be separated out into different sites later if required.
As a side-note, one advantage I had not previously considered for the multisite setup was the reduced amount of memory required to cache compiled PHP code (detailed here).