That's great to hear!
Yes, in fact the plan was (and is) to keep the entire tileset in a single zip file and extract individual tile files on the fly. This would avoid having to unpack and keep an enormous number of small files on the disk, which can cause various problems.
If keeping the same number of compressed files on disk wouldn't be a problem (i.e. each tile would be a zip file), then the below problem wouldn't exist:
There are a few drawbacks with the zip archive approach, e.g. how to merge multiple zip archives for local tileset replacements (e.g. from base addons), or how to edit individual tiles inside the archive.
I understand that Doug has already written some working code, which is great already, but if you're able to abstract the Orbiter's "TileRequest(x, y, level)" call, then a contributed module could use the other option (read each tile from a separate zip file).
Also, don't get me wrong, but the caching functionality would probably need to be optional, since it kind of kills the purpose of zipping: Firstly, it would bloat the Orbiter installation, and secondly, it would increase the amount of work that the HDD had to do in the same time, when you need it for reading the zip file(s). I can imagine the HDD's head jumping from one sector to another in such scenario, thus slowing down the read process... unless the tile's source was indeed a network share.
[EDIT] One thing to keep in mind, is that in the spirit of the idea of unzipping is, that the unzipped tile should go
straight into the memory, and not be placed on the disk.