Thanks for taking the time to understand how the terrain and imagery systems work. You’re asking some good questions, so let me see if I can address them.
First, you should take a look at the “terrainRefactoring” (https://github.com/AnalyticalGraphicsInc/cesium/tree/terrainRefactoring) branch in GitHub. I’ve made substantial changes to how the terrain and imagery load state machines work, and I think it’s much more understandable, less insane, and will make it substantially easier to write TerrainProviders. I just need to hook the water mask support back up and then I’ll merge it back into the terrain branch (and hopefully master soon after that).
I believe it now correctly does something the previous code had intended to do, but failed at: it will refine imagery without necessarily downloading terrain data. This works by upsampling the terrain in parent tiles for use in child tiles, which often (but not always) is just a matter of dropping 3/4 of the posts. Subjectively, the terrain and imagery refinement seems much more responsive, now.
About your suggestion that tiles render as soon as the base layer is ready: that would be an easy change, but I avoided doing it for fear that it would create some very objectionable popping artifacts. With a slow non-base layer, every time you moved the camera, you would see the base layer first, and then the slower layer would pop in over it. Perhaps we could make it a per layer option?
Better than that would be to use parent imagery tiles if child tiles aren’t available, on a per-layer basis. So your fast base layer would refine immediately, and the slower layer on top of that would initially be a low-res (parent) version until the slow child tile actually loaded.
With such a system in place, we could allow “refinement” of both terrain and imagery without regard for what data has actually been downloaded yet. That puts us in a much better position to select which tiles to download first, rather than the current strategy which is basically depth first. The tile load queue is actually already a priority queue, but it is tuned to give the highest priority to tiles with a lower level in the tree. I think this is appropriate for many use-cases (such as when zooming in from space at a reasonable rate) but gives us a lousy experience when the camera starts zoomed in or the user zooms in very quickly.
Another idea is to allow imagery providers (especially the WMS one) to apply to multiple extents instead of just one. You should see a big performance improvement from that in your use-case, because the imagery system is currently rendering fully-transparent images over the entire globe.
It’s going to take me a little while to get to all of this, and a lot of it might happen after the merge to master. If you can help out, though, I’d definitely be grateful. The multiple-extents-in-WMS would be a great place to start if you’re up for it. Please do start with the terrainRefactoring branch, though.