Drush pm-updatecode gets really confused by corrupt module / themes

I think Drupal makes neither of those assumptions. You can have

PROJECT: foo
bar.module
bar.info (in this file, we may find project=foo line)

I've just had exactly the same problem. I think the case is probably more that sub-themes in separate folders shouldn't have the same project name as the base theme, perhaps because drupal assumes that if two folders have the same project, then a higher directory (first common ancestor) must be the project's parent directory?

I had:

sites/
  all/
    themes/
      zen/
  default/
    themes/
      blah_zen/

and the error was:

The zen directory could not be found within the themes directory at /homeblah/public_html/sites, perhaps the project is enabled but has been deleted from disk.      [error]

Which is the first common ancestor directory..

Maybe not, but changing the "project" setting to something unrelated to either the directory, .info file name, or the zen project worked fine for me (I forgot the underscore, so I had project = "blahzen")

#2 worked for me. For a sub-theme it probably makes the most sense to delete all the lines added by the Drupal packaging script (though I didn't try this).

I would also support #3 in deleting delete all the lines added by the Drupal packaging script. In my case (I have adaptivetheme and it custom subtheme) drush up command was deleting the subtheme folder leaving behind the latest version of AT and backing up the custom AT subtheme folder as adaptivetheme in .drush-backups. This was till the time I had only AT and my custom AT sub-theme in the site/all/themes directory. Later on I added Marinelli and genesis too for testing. Now, it seems there is a bigger problem than this. Today I updated AT again (without knowing about or implementing #2 above) and look what happens:

1. drush deletes themes folder in the sites/all directory and replaces it with a folder named adaptivetheme (containing AT core, AT admin theme and AT starter subtheme). All the themes and themes folder gone only adaptivetheme left (latest updated version).
2. Drush makes a backup named adaptivetheme in /.drush-backups/[current-date]/themes and place all the content of sites/all/themes folder in it (i.e. including Marinelli, genesis and my custom AT subtheme - as if it backed up the theme folder).

I have not tested it after correcting the error mentioned in #2 above but I am in doubt because in my latest attempt it even deleted all the themes other than my custom AT subtheme. I apologise if I posted this in the wrong post and should have created a new issue.

If project = is set in the subtheme's .info, drupal consider that subtheme as part of the project. Drush find for the common path for all extensions in the project. naught101 is right in #2.

I think the most we can do here is to abort execution if the found common path is sites, modules or themes.

related issue: #809170: drush removes the sites directory when updating a module named sites

to reproduce:
* create a subtheme of zen (or adaptivetheme or...)
* put it outside the main theme's directory (sites/all/themes/zen and sites/all/themes/green_zen)
* enable both zen (or zenclassic in zen 1.x) and the subtheme green_zen
* drush pm-refresh
* drush pm-updatecode

This way, update.module will add your subtheme to the array of enabled extensions of the project. That array is used by _pm_find_common_path() to obtain the install path for the project.

Note there's no other way to get the project's install directory. We can't rely on project = because of content != cck and in general we can't expect the parent directory to be named the same as the project (drupal itself recommends cck-6.x-2.4 as a directory name when using a cvs checkout).

The flaw in our approach comes in play when there're two or more extensions with the same project name and they're not within the same ancestor directory.

Looks good. Committed.