In my opinion, the biggest drawback of the current format is that it is all one big blob of file-data. Very efficient for loading and distributing, but for new graphics, it means you have make all graphics before you can distribute any of it.
Instead, you want to distribute in smaller pieces. As a starting point for the discussion, let me show what I have done in my project.
I don't expect that you will want to copy the data+code as-is, but rather use some of the concepts of it, and adapt them to your needs.
In the FreeRCT project I have taken an opposite approach to the one big blob idea. Everything is a small piece, even the standard things. All stuff is free in the project, so I assemble the data files as part of the build process currently. It is however the idea to allow others to also make such data files as well somewhen in the future. A file starts with a file header (to recognize it is 'your' file), and then a sequence of blocks with varying content. Each block has a name, a version, and a length (for easy skipping to the next block, and for size checking). Blocks can refer to previous blocks (enabling sharing), first block gets number 1, second block number 2, etc. Block 0 is the 'nil' block for references to 'nothing'.
The description of the data file format is in http://code.google.com/p/freerct/source/browse/trunk/rcd/data_format.rst
The file header is described near line 41. The remainder of the description is a long list of different blocks. For example near line 60 starts the description of how an image is stored (just look at what it contains, don't try to read all details. You may of course also read the details, but quite likely it will change anyway). Lines 68-70 is the a header of a block followed by a bunch of fields. A simple graphics block is at line 390, the BDIR block contains 4 arrows pointing in the direction of building. (Most other blocks that exist currently are just endless variations of tiles with one or more corners lifted up, not very useful as example.)
In FreeRCT, there are also blocks with complete game elements, eg like lines 326-370, in this case a little shop selling things to customers. It defines all elements that are part of a shop object in the game (that I needed so far, but it will expand probably).
Note that every block has the same header, with a unique name to distinguish blocks from each other.
Besides the documentation, there are of course also actual input files. I have not yet settled for the final input format. I tried native Python first, my current generation is an XML input format, in the end I expect to have some nice text format. The shop input-file that defines a single shop looks like http://code.google.com/p/freerct/source/browse/trunk/rcd/shops.xml
Please ignore the horrible syntax, and instead just look at what type of data you have to enter. All XML horribleness around it can quite easily be changed, I just have not found the time to make it nicer yet.
Finally, there is also a meta-xml file, that defines what you can enter as input, ie a machine-readable version of the data format description. (XML turns out to be quite useful for this.) Useful for a project that is expanding without knowing upfront what is all needed at the end (like with FreeRCT), perhaps less useful for CTH.
If you want a modular file format, I think this is a feasible way of doing it. The blocks make it very flexible. The version number in each block makes it easy to change a block definition. Depending on what you want, you can either refuse, load and upgrade, or ignore old blocks when you encounter them.
The current block contents is likely completely useless to CTH.
You likely want to have a different pixel format, iirc CTH just uses W*H bytes images, much less complicated than the format I use currently. If you want a different type of graphics, that would also be possible, a block can carry anything that you can express in bytes of data
As for the other blocks, the sky is pretty much the limit. You can just define a block for replacing sprites (ie a reception desk in 4 orientations), have an 'object' with all its properties, or even define a 'room' with everything in it.
I have plans to use the format for save games, and scenarios as well.