Hi there HeadClot 
Orbit works well with very large maps, I’ve tested some rather large landscapes very recently with my focus shifting towards weather effects on materials (including terrain) using material functions, and it performed at the same pace and quality as it did with smaller maps. Parameters are exposed to allow you to control the scale of each individual piece of the system, (dynamic stratus clouds, backdrop clouds, starsheet, sky coloration sphere, moon and sun) so you should be very easily able to scale the system up to whatever world size you like.
I’m not super familiar with networking, so I’ll try to answer this to the best of my abilities: I’m building the framework for the runtime stuff as soon as I finish the visual construction of this system. The plan is to allow for the user to select from weather patterns or create their own, and then have the user set the probability of each weather pattern being called. When a particular weather pattern (likely to be identified via an enum stored in array) is called at runtime, it’ll fire into a struct that will contain the necessary variable values to form that visual weather pattern.
So yes, as I’m typing this out it’s clicking (at least in my mind) that a manager class could store the same enum array > struct layout, and then fire out the struct information to the clients (if that’s the right word, the players, I guess) which would be awaiting that data anyway to display the proper weather values synchronously.