The right way to reuse update.module functionality

For the translation template extractor and for the localization file update functionality via localize.drupal.org, I clearly need something just like update status module's project identification functionality. What I need for extraction and localization though is to be able to identify all projects regardless of CVS / drupal.org availability or their enabled/disabled status.

Therefore I wrote two little functions in my upcoming potx.module patch, which tries to achieve this. One alters the project list by including all disabled modules. I looked at update_advanced, and seen it is done way more complex there, but could not find any reason for that complexity. We could just reuse code for the enabled stuff and pretend our items are enabled as far as I see. I already make the module dependent on update.module, and definitely did not want to make it dependent on update_advanced, so put this little code in, knowing it has side effects for update.module in general.

However, the more problematic piece is projects which are not identified by update.module. These will not show up on the UI of potx / localization updater. However they might come from a source via drupal.org but being without project information. So I've built in optional support for cvs_deploy, but still then, I need support for custom module identification for extraction a possible localization updates from remote servers other then drupal.org. So I built in a very simple top directory identificator to the code, so that sites/*/modules/mycustom/* will be identified as belonging to the project "mycustom", etc.

Now all these are nice and dandy for my own code. SVN checkouts like bluebeach and bluecheese show up in potx (they would not show up with update and cvs_deploy combined), I have mycustom showing up, so I can extract from my own stuff as well as internal private things.

But then because these were implemented via standard project and info altering hooks for Drupal to take advantage of all the rest of the project identification code in update module, now update module contacts drupal.org with projects like bluebeach and bluecheese and mycustom asking for data about them. Obviously there is no data available for them, so it has no luck.

I was looking to somehow overcome this by saying that these are identified projects but update module should not look for an update server for these. Ie. I would set the update server URL to NULL or something, but the existing code will default to the default server in that case. I can set it to something invalid, but then Drupal will attempt HTTP requests to that invalid address to figure out it does not work after a while, and then keep trying later. Not nice.

It would be great to somehow be able to reuse and extend the project identification functionality without the update functionality actually running for modules we know it should not run with.

Am I doing something wrong? Do you have better suggestions? Should we add fixes to update module to allow for this?

Ps. I've marked this issue Drupal 6 because I'm working on the Drupal 6 potx.module functionality. Patch and screenshot at #624370: Filter strings by module. Also, I've posted this as an issue, so it is documented for the community for others who want to reuse.