The borders are fuzzy at some point. Prefetching resources on demand can be done on in-game triggers if you want to avoid the loading screen. You just need to detect which resources will be needed next and which resources can be dropped now. The former one can be done on proximity or on explicit trigger volumes, while for the latter aspect also a decent resource cache system can be used. A more elaborate prefetch system may start with low detail level resources, and prefetch successively higher levels when needed.
A Clip-map (and its derived work MegaTexture and Virtual Texture) actually load LODs on demand, IIRC, but are intended for handling very large textures instead of dealing with totally exchanging the appearance. However, technically the difference is small to a texture management with prefetch and caching considering LOD.
The texturing system I currently use in my engine ( which I am writing for educational purposes as well as a hobby ) is based on a texture array. I use each layer as an atlas except in the case of textures that need to be repeated, where I resize the textures to the maximum resolution and fit them into their own layers.
Texture atlases are usually somewhat big, say 2k by 2k. Upscaling repeatable textures just for the purpose of fitting them into the one texture array seems me a bit strange. When the texture is relatively small originally, this would waste much texture space.
The problem with this is that I do not know if I even *can* 'stream' new textures into the same texture array
Yes, it is possible to replace parts of textures. However, the question is whether this would not block the entire texture from use by the rendering process or at least would introduce another temporary copy. I assume that in case that a GPU command is still queued that access the texture for rendering, an update on the texture will cause some inefficiency. This would at least not occur when using different textures where the targeted texture is known to be obsolete (its similar to double buffering then).
