An app with module and library of the same name fails.

I added a bunch of stuff to segment each downloadable by type so that this isn't an issue anymore.

The advantage to grouping them is that we don't have to keep track of each random string for each dependency/library.

Here is the sequence of events that happens.
The zipped archive is downloaded to /tmp/update-cache-XXXXX
The archive is unzipped to /tmp/update-extracted-XXXX
The folder is moved to it's final location

This problem revolves around the colorbox module for now. There is both a library and a module that when unzipped are contained within the colorbox folder. This is causing the conflict.

So...

Colorbox-7.x-1.x.tar.gz is downloaded to /tmp/update-cache-XXXXX
colorbox.zip is downloaded to /tmp/update-cache-XXXXX as well
In the pre-patched version of apps, there is a bug in that both the library and dependency are placed within the dependency array which caused one of them to disappear since they both had the same key of "colorbox"
Once I straightened that out and kept the colorbox library under the libraries, it would not extract them both since they would both attempt to extract to /tmp/cache-extracted-XXXX/colorbox. After the first one ran it would assume that the second one did not need to run. In my instance it would then copy the library into the sites/all/modules directory which is not at all correct.

To fix this what I did was to namespace them using the type of download they are; library, module or app. This made it easy to group so that on the step when we copy the directory into it's final destination we could find it again because we know what type it is.

The problem with namespacing them with a random string for each one is that we would have to keep track of the random string for each module and pass it along to the install step so that we know where to find the module when it comes time to move it.

While I do see the case where there are going to be modules and libraries that collide in the namespace quite frequently, there really shouldn't be themes, modules or most other things that collide. If they do, it will cause major problems within drupal. Breaking them into libraries and "other" would probably even solve this.

I like that. I'll look into it.