How to upgrade common code base multi-site installations

I have a multi-site installation using a Drupal common code base: "mydomain.org" in fact has multiple sites, one for each language (eg, en.mydomain.org for English, fr.mydomain.org for French, bn.mydomain.org for Bengali, etc). Each subdomain is redirected to the directory where the common code base is installed - since I'm in the middle of an upgrade from 4.6 to 4.7, some subdomains point to a directory called 460/ with the Drupal 4.6 codebase, others to 470/ with the 4.7 codebase (and there is even a brand new site which was built directly in 5.1 and which points to 500/ with the 5.1 codebase).
In this situation, the upgrade process so nicely described by the Lullabot video simply does not work, for two main reasons:

1. The process involves an upgrade in situ, in other words overwriting the site's existing code base. This is not acceptable because if I overwrite the codebase for one subdomain, I automatically overwrite it for all the others as well
2. The only way around that would be to upgrade all the sites in one go. However, given the number of sites, and the amount of reorganisation that is being done as part of the upgrade process, this is simply not a realistic proposition

I do have one advantage: these sites are purely "publication" sites, they do not have thousands of users logging in to leave comments. On the other hand, I don't want to take the site down for the time it takes to do the upgrade and the reorganisation.
All this means that my upgrade strategy is going to be very different from the one described by Lullabot: instead of taking the site offline, upgrading, then putting the site back online, I intend to copy each site into a parallel location, do the upgrade, and then switch the appropriate subdomain redirect so that it points to the new codebase with the upgraded database.
The question is: how to do this in a way which is easily repeatable, ie it can be "industrialised" across all my sites, and then repeated identically every time I do a new upgrade? This industrialisation of the process is all the more important in that (in the current case) I plan to upgrade directly from 4.6 to 5.1, passing through 4.7 on the way.
One possibility might be to use a scripting language (like cURL?). The problem with this is that:

• I would have to learn the scripting language
• I would have to write and test the script, which would probably take at least as long as the upgrade itself
• I could not guarantee that the script would work in the same way for the next upgrade

Here is the first idea I had:

1. Setup
   1. Create a database called "upgrade"
   2. Create subdomains upg46, upg47, upg50 with redirects to the directories 460/, 470/, 500/ respectively
   3. Configure all these subdomains to use the same "upgrade" database
2. Operation per subdomain
   1. Dump subdomain database (eg "en_db460") and load into "upgrade" database
   2. Login as admin to upg46.mydomain.org
   3. Switch to Bluemarine theme and turn off all contributed modules
   4. Run the script upg47.mydomain.org/update.php to upgrade the database to Drupal 4.7 (don't forget that, in effect, all the different codebases point to the same database)
   5. Login as admin to upg47.mydomain.org
   6. Switch on the contributed modules and run update.php, then switch the contributed modules off again
   7. Run the script upg50.mydomain.org/update.php to upgrade the database to Drupal 5.1
   8. Login as admin to upg50.mydomain.org
   9. Switch on the contributed modules and run update.php
   10. Switch my own theme back on
   11. Dump the upgrade database into a new subdomain database (in this example, "en_db500")
   12. Set up the configuration for the subdomain in the 500/ codebase
   13. Switch the subdomain redirect from the 460/ to the 500/ directory
   14. The upgrade is complete! And of course, should I find an error, I can always go back to the original database simply by switching the redirects back to their original status

Unfortunately, I could not get this to work, for one simple reason: the update.php script requires you to be logged in as administrator to do the upgrade, and of course by changing subdomains (in order to switch codebases), I lost the administrator login each time.
So I had another try, which goes something like this:

1. Setup
   1. Create a database and a dummy directory both called "upgrade"
   2. Create a subdomain upg with redirect to the directories "upgrade", connected to the database "upgrade" (when this is done you can get rid of the dummy directory)
   3. Create copies of the 4.6, 4.7, and 5.0 codebases in 460up/, 470up/, and 500up/ respectively
2. Operation per subdomain
   1. Dump subdomain database (eg "en_db460") and load into "upgrade" database
   2. Rename 460up/ to upgrade/
   3. Login as admin to upg.mydomain.org (here I am connected to a 4.6 DB of course)
   4. Switch to Bluemarine theme and turn off all contributed modules
   5. Rename upgrade/ to 460up/ and 470up/ to upgrade/
   6. Run the script upg.mydomain.org/update.php to upgrade the database to Drupal 4.7
   7. Login as admin to upg.mydomain.org
   8. Switch on the contributed modules and run update.php, then switch the contributed modules off again
   9. Rename upgrade/ to 470up/ and 500up/ to upgrade/
   10. Run the script upg.mydomain.org/update.php to upgrade the database to Drupal 5.1
   11. Login as admin to upg.mydomain.org
   12. Switch on the contributed modules and run update.php
   13. Switch my own theme back on
   14. Dump the upgrade database into a new subdomain database (in this example, "en_db500")
   15. Set up the configuration for the subdomain in the 500/ codebase
   16. Switch the subdomain redirect from the 460/ to the 500/ directory
   17. The upgrade is complete! And of course, should I find an error, I can always go back to the original database simply by switching the redirects back to their original status

I think this works (I'm still in the middle of the first upgrade) - though of course it is much more fiddly than the other process which looked nice and clean! And of course, if you are upgrading from 4.7 and you have lots of users there is nothing to prevent you from closing the site while the upgrade is in progress. I would welcome some comments on this, and if there are no negative comments then I would happily offer to contribute it to the Drupal handbook as a special procedure for upgrading multi-site installations.
Even better, from my point of view, would be if Drupal upgrade could be modified so that the first process worked properly.