i mentioned that i’ll write a techpaper on it^^ it’s pure theorey atm. although i tested a few thing to prove that the concept itself works it wasn’t coded so far.
actually it does the same with textures like a lod would do for terrain.
splitts the terrain in pieces (usualy already done by the terrain algo, in this case geomipmapping would be the one) and then render textures for it (not with multipass but simply a texture-rendering off-screen. a stack of 2d cardmaker objects are enough to put up the single textur “layers”. the resolution depends on the camera<->terrain patch distance.
usualy you wont use more than 5 or 6 textures per terrain patch(it’s possible to use as many as the zbuffer can sort 
).so rendering those images should be quite fast (and it’s an ortho camera so it might be faster ) . and it doesnt have to be done each frame, only if the camera moves and the detail level has to be changed. (usualy a threshold of half an terrain-patch)
this costs a little texture memory but i think it could be more effitient than multipass rendering AND you tweaking the quality is possible “on-the-fly”
well like i said . as soon as i have the time i’ll write a techpaper with some illustrations and some math 0) (unfortunately i’m currently busy with finishing up some hardware-development and projectmanagement, but i’ll answe your questions if you have some 
)
well this should work well together with geomipmapping and paged terrain =)