I still have plenty of researching to do on the subject but here's what I got so far:
The benefits of streaming textures are twofold. Frist, the initial loading of a scene only needs to last until the necessary mip levels are loaded and the rest can be streamed in later. And second, the memory footprint of textures can be reduced (allowing a higher level of detail per frame). There's an important point to make at least in the OpenGL case here. As far as I know if the available memory in the GPU is exceeded OpenGL allows continuing to load textures intro normal memory and the driver can handle swapping it to VRAM latter. To properly estimate how much texture streaming will help I still need to find more details on how good it is at doing that. Also, in general with modern GPU having truckloads of RAM, I could use some help evaluating the actual impact this project would have on the community, how many people would really benefit from it.
Streaming involves dynamic loading and unloading. The efficiency of the approach depends on how well the times are chosen to perform those operations. With calculating the exact time to load a particular mipmap being fairly complex, an approximation based on distance and orientation to polygons mapped with the texture can be used. To get around doing it for every polygon a more rough estimate can be obtained for a particular texture by taking the shortest distance to the bounding box of an object mapped with it. If the camera is moving towards such an object, enough time should be left to do the load by the time it gets close enough. So the user should be allowed to set a speed factor depending on the maximum speed of the camera. If I understood correctly, blending through shaders will be needed when the new texture fails to load fast enough and then that will help reduce the popping effect ?
Based on remarks from "Pro Ogre Programming" and on the fact that WorkQueue::addRequest is only callled from terrain/paging code it is possible to put a new request in thread pool from the application side to manually load a texture but the loading code in Texture uploads all mipmap levels to the hardware buffers. The main loading loop will need to be refactored to allow loading specific levels separately and then separate requests could be added to the work queue for them. This introduces several thread safety concerns, the mip levels are looped over in several other places. Thread safety seems like an issue even without separating mipmaps, there doesn't seem to be any guarding against unloading the texture while it is being loaded for example.
To be continued .. well, maybe next year of if i find more time.
Any feedback, suggestions or advice quite welcome
.
) I thought I should mention that I was thinking about not necessarily loading the 
) when first displayed but only if the camera moves too fast in the direction of textures that need mip levels not yet loaded and that other hand could be fixed by the speed factor and some blending. Of course getting the formula just right will probably be the last things I will tackle as there's plenty of other things to do up to that point. In the design I will definitely want to explicitly allow multiple strategies for this, to decouple it as much as possible.
