Assuming most customization will be done in the template pages, ad_return_template could be hacked, or just add the correct path to the call to ad_return_template.
For Mydomain.com, I just provided dynamic options to ad_return_template to pick the template I wanted to run based on the Host: header, as well as the requested page. Actually one tcl script served multiple templates in a single instance. So ad_return_template lets you choose the template name, plus the directory of where to get the template. That is one problem I solved without needing to change any core code.
The second issue was the use of the include tag. Although it seems interesting to have a tcl page associated with every template, I have a very complex template page that had lots of conditional code. I wanted to have a simple template that could include the different parts in a way easier than using the include tag. Also the include tag has the nasty feature of requiring you to pass all the variables you need to use through to the included template. Since I had perhaps dozens, if not hundreds of variables, I might use, this was impractical. I created a very simple tag that would just evaluate the template at the current level. (This is what I thought include meant, but I guess that tag really functioned more like ns_adp_include, which required you to pass any vars.) Anyway, another problem was the relative/absolute distinction. There was no way to access a template with real absolute filename. So I had to hack how the src attribute worked in things like the master tag. The main problem with my new tag (I think I called it something stupid like 'read'), was that if you changed the sub-template, you needed to touch the main template to kick the cache into reevaluating the templates, that is, the templating system didn't check the mtime of the sub-templates. This really only affects developers, so it isn't a big drawback.
Overall, the package needs to be written to work this way, only minor changes would need to be made to the OpenACS core.
