The basic idea is that the client and server could be a lot smarter about getting updated images to the client.  This may be related to dynamic content.

Currently, images are handled by sending a checksum for each image, and then client downloads those that are new.  This works, but makes doing all this checking at start up too slow to be feasible, even on fast links.  And for the most part, this isn't very efficient - images do not change very often.

Instead, I would see the server maintain a table like:
  #base_Revision    update_revision checksum     URL
  2353             2353            23896752987  http://foobar.com/img2353  ftp://abc.org/img2353
  2353-local       2353-local      23723098638  http://foobar.com/img2353-local ftp://...
  2353             2985            35489345842  http://foobar.com/img2353-2985 ftp://....
  2985             3142            ...          ...
  2353             3142            ...          ...


In that first line (2353/2353) that denotes the basic image package.  Ideally, an updated client is distributed with that image set, so client wouldn't need to download it.

The second line is used to denote the local changes the server has.  For example, the user may have downloaded the server, added a couple archetypes, and thus now has that local set.

The next line (2353/2985) is an update package.  The server was updated to version 2985 of the archetypes at some point, and that is now the file to get images up to date at that point.

Following lines (2985/3142) denote that server has now been updated to version 3142.  There are two updates available - one to go from the base to that version (2353/3142) and one to go from the last update to latest version.

The advantage here is that it makes it very quick for the client to know what image files it needs - it looks at what revision it has, and see what it needs to get to.  The download may still take a little while, but downloading few big files is almost certainly faster than many small files.  And by using URL, it is now possible to put those media files in fast locations.

I believe most of this could be done automatically - the collect script (or whatever) just has to keep track of what has changed - maybe the bmaps file now includes checksum values, and collect script reads that in so it can see what is different.  There would also need to be different versions of the bmaps file stored away, but not a problem there.  Ideally, rather than the bmaps always being written in alphabetical order, new images get added on the end. In this was, the name to number mapping also remains constant and doesn't need to get sent down every time.  The part that would likely need to be manually done is putting the files on the ftp/web server.  Probably needs to be some confirmation on this being pushed update.  For example, I might be experimenting and running make collect a bunch of time with an image here and there - not until I'm finished do I want to bundle those into an updated revision.

For folks using official server releases with no added archetype, it means that it will know very quickly it has an up to date image archive.

I'd suggest that this be made the standard way, so all the messy caching of data on the client gets removed - at start, it will know it has all image data it needs at hand.  And if the image to name numbers is also stabilized, it means that code goes away.