We have to files related to zip files: zipfile and zipimport. Should we bother to consolidate? The problem is the obvious names conflict with built-in type and a keyword, respectively. A possibility is:
zipfile -> zip.filer zipimport -> zip.importer
But I don't know if that is really an improvement. What do other people think?
If you go down this road, then make it a compression package and add bz2, gzip, etc. There was a definite improvement when hashlib was introduced and a common API for hashing routines was enforced. But, simply packaging two completely different zip modules is of dubious benefit.
Here's a general comment on the new package proposals like zip and cookie. When people are looking for stdlib improvements, I don't think they had in mind introducing a new package everytime there were two related modules. Packaging is not free -- it complicates importing, searching for source files, and makes the user have to rememember both the module name and the package name.
For me, the searching part really bites. At work, we have a utils package which consists of a dozen unrelated utility files. When you see code like "from utils import reversedict" you don't automatically know which module to look at to find the source code to see what it does. Likewise, the multilayer directory structure complicates using grep (it's no fun always writing find . -name "*py" | xargs grep 'sometext').
Also, packaging exacerbate the existing annoyance that occurs when a class name closely corresponds to a module name. It already feels redundant to write "from zipfile import ZipFile". It will be even more annoying to write "from zip.zipfile import ZipFile". Yucko!
IOW, the conceptual benefits of grouping theme related modules can be more than offset by the expense of introducing another level of indirection. Packaging should be a last resort rather than a first resort.