I just downloaded the 32k blue marble virtual texture, along with a few select level 6, 7, 8, 9 and 10 add-ons, and it looks great. This is a good arrangement as it allows us to optimize things accordingly, i.e. water/oceans are basically featureless; one single seamlessly repeatable, low-res texture would suffice using softlinks to create the appropriate filenames that all point to the same resource. However, while this is storage-efficient it is not memory-efficient; multiple copies will need to be stored in memory unless there is already code in place to avoid this. (If there isn’t yet, I’m sure it’s on the to-do list.)
Another problem exacerbated by virtual textures: massive file sizes. We’re looking at near exponential increases in file sizes with each additional detail level (although as stated previously, optimizations will help moderate this somewhat). This is bad for downloads and bad for storage requirements. There are a number of ways to partly address this issue, like distributing virtual textures in jpeg format, along with an easy-to-use utility to auto-convert them to the desired format (such as DDS). But why use DDS, at least why use that format for level 5+ virtual textures? Wouldn't it make more sense to use jpegs? It's true jpegs will take up more memory as they will need to be decompressed before Celestia can use them, but this is less important with virtual textures and limiting storage requirements has became more important. Something to consider.
There are a bunch of things I’m glad to see were introduced, like the ability to label locations for things on a sphere using latitude/longitude coordinates, and the ability to use “alternate textures” which, as an example, can be used to display non-topographical data.
But there is still much to do. A few examples follow:
1) The ability to specify more texture layers; why even leave the hardcoded “cloud layer” in, other than for legacy compatibility? Generalize it, and remove any theoretical limits on the number of layers that can be used, with various masking/composition options, etc.
2) Extensions to the current lat/long labeling system; instead of just labeling a single long/lat coordinate on the sphere, why not allow us to group multiple long/lat coordinates to specify, label and manipulate regions, paths, etc (i.e. draw political borders, with all sorts of masking options to change the presentation of the polygonal region).
3) A more powerful and flexible animation system…of course! :p
4) A system that allows more dynamic content (stuff that changes with time; not just the relative positions of celestial objects). For instance, the feature mentioned in number 2 above could change with time, i.e. sit back and watch as the political borders change over time. But you should not be restricted to just those sort of things, of course.
So much to do, so little time, eh Chris?
I have no doubt you have a mile-long to-do list.