May I suggest...
When you're setting up dev and staging and QA and production environments (etc.), it's better to change the XML, not the XSLT. Forking for different servers should happen much farther upstream.
I presume you are generating XML data, which gets transformed into HTML pages, right? In production, you need your XSLT layer to be fast, streamlined, elegant, maintainable - free of unnecessary string manipulation, logic, and clutter.
Put the effort in on the back end where your XML is generated so it uses the right domain or subdomain, not in the middle layer which you would ideally like to keep finely tuned for performance.
If you're on the dev server, your XML should deliver links to the dev server. If on production, your XML should contain links to production. It's easier - keep your codebase identical on all servers, but use a global config file which you do not deploy to the production machine.
On dev, your config says:
$localserver = "http://dev.example.com"
On production, your config says:
$localserver = "http://www.example.com"
Then your XML engine should use that setting to construct all links. The XML rendering is identical, the XSLT is identical, and everything (except that one magic file) can be tested and deployed from one machine to another without causing any grief.
The global config file is also where you store any database connection strings, should you want to separate your databases into dev/staging/production as well.
See what I mean?