With the release of the NV G80 based cards a whole load of new extensions have come to light, one of them allows you to have GLSL samplers bound to arrays of textures, allowing you to use one of the texture co-ordinates to index into this array.
This is a pretty cool extension and should allow for some intresting things, it also remove the need for hacked texture atlas as instead of using a 3D texture you can use a stack of 2D textures instead (which can have mipmaps as well per level).
However this is a lack of tools to produce image formats of this nature and an even bigger lack of a file format, although I suspect the DDS could be made to work with it as it already supports cubemaps.
So, yes, taking that as our inspiration a system of images and mipmap levels could be generated, with a header either per file (for uniform texture sizes) or per texture in a file.
So, the file layout would look something like;
[details about the following textures]
[texture 1 inc mipmaps]
[texture 2 inc mipmaps]
Now, given that I quickly realised that, if we assume uniformed sized textures, GTL can handle that with only the addition of an extra parser. The library already supports multiple images with mipmap levels so that it can support DDS files which are cube maps, and this is to a degree an extension upon that area.
Even with non-uniform sizes, while working out the stride becomes a little bit tricker, it can be dealt with via some behind the scenes magic which need never be an issue for the caller; you ask for data from a perticular image at a perticular mipmap level and the lib does all the hardwork for you.
So, now all I have to do is;
(a) get people using the GTL
(b) convince people that this is a sane format to follow
Given the 'no made here' phobia however this might not be all that easy... [sad]