That would require like a new global table, with theme information most likely.
The way themes work now, through the get_themes function (wp-includes/themes.php, for reference):
Every single one is read from the themes directory.
So that's X number of directories (however many themes you have), plus it reads 2 files per directory. It reads style.css, and also reads index.php so that's X*2...
And, the presentation page isn't the only one to call this function.
On a standard WP install, I can see this not being an issue.
For an MU install, where the total number of themes is (most likely) much much higher, and the users much greater, it seems like it might be possible to save all that overhead with a simple DB call.
What would eat up less resources? Reading in 2 files per theme, or a database call to a global table that returns say 5 or 6 cells per row (1 row = 1 theme)?
"Technically", a theme isn't there until it's activated under Site Admin. So since that page is visited much less often than a users presentation tab, could that page run the checks on the current themes in the dir, and then once it's activated stick it into this global themes table?
Maybe I'm just nuts. How many themes do your sites have available? Farms? Quentin? Andrea?
I know initially I'm looking at 25 different themes to start with, but I could see it getting upwards of 100 or more. The more to offer, the better right?
Of course, if someone edits a theme, and mucks it up, it would still be active. Then again, I can't imagine anyone operating at this level not working with a theme offline before uploading changes. Also, of course, unless it's an error in the commented portion of the stylesheet or deleting index.php, it's not going to be picked up by the current method anyway.