Thanks, Jake! A couple of questions/clarifications about this info:
Just to clarify: if the new scene has light probes, it’s a total replacement of light probe data? Meaning, the existing probes are all discarded, replaced by the probes from the new scene? And I guess a second question about this: barring bugs/inconsistencies, should this behavior apply to all types of scene loads? (ie Additive, Single, Async Additive, Async Single) Or is there expected variance in this behavior depending on scene load mode?
One question regarding these suggested options. But first, some unfortunately lengthy background info…it’s my understanding, and experiments seem to bear this out, that 5.3.4f1 supports two different approaches for additive scenes + precomputed GI (this probably applies to other lighting as well, but I haven’t experimented with anything else):
-
Use MSE to load all scenes in the editor and build lighting. LightData is saved as an asset in the folder for the active scene, and contains a LightData sub-asset for each scene that was present via MSE during the lighting build-- a reference to the corresponding LightData sub-asset is set in each scene. When the primary scene is loaded (non additively) at run time and other scenes are subsequently loaded additively, all the GI just works (without visible seams) because the lighting for everything was built together. In our setup, the process for this method is: load OcclusionAndLighting in the editor and bring in all the World scenes via MSE. Make sure they all have realtime GI checked and OcclusionAndLighting is the active scene. Build lighting. Save all scenes.
-
Build lighting for each scene individually, having only one scene loaded in the editor when each lighting build occurs. Each scene gets its own LightData asset in its own sub folder. At run time, when such a scene is loaded additively, Unity is able to merge the precomputed GI data with what is already loaded and GI functions more or less as expected, though there will be visible seams if there are any areas where geo or GI in additive scenes overlap spacially. In our setup, the process for this method is: just build lighting individually in each World scene, with precomputed GI checked. Additionally, we needed to select a scene that will be loaded non-additively as the base active scene for GI, the scene must have precomputed GI checked in its lighting settings (though it need not actually have built LightData), and SetActiveScene() may not be used any time after that base GI scene is loaded. Any deviation from those three rules results in GI not functioning properly in standalone or console game builds (though play in editor GI is fine even when breaking some of the rules): depending on which deviation, GI will come out either solid black or almost completely white with just the slightest hint of the expected GI color/intensity. In our setup, we use OcclusionAndLighting for the base non-additive active scene, then additively load the SharedStuff and World scenes.
We are using method #2. We don’t care about lighting seams because the things in our scenes are not near to stuff in other scenes. The primary reason we are using #2 is build time and workflow convenience. Our precomputes/builds take a significant amount of time, even for individual scenes. We first experimented with method #1, but it turned out to not be a feasible option due to build times. #2 also fits better with our decision to break up the game into all of these sub scenes in the first place: compartmentalizing the game spaces, facilitating concurrent editing, and reducing central/shared dependencies as much as possible.
I include all that info as background for my actual question, plus just to get the info down somewhere in case it could be useful for anyone in the future doing web/forum searches for this stuff. 
My actual question: I think if I am understanding you correctly, the two options you suggested will only properly work with a monolithic/combined lighting build (method #1), since we’ve established that light probes are not currently mergeable at run time and thus need to be built with all lighting + probes present at the same time. Is that accurate, or is there an incorrect assumption I’m making about something? I just wanted to clarify that, because if that is accurate, then deciding if we can realistically switch to that lighting build method should probably be a prereq before doing any more investigation and experimentation with light probes in our current project.
(Also, please feel free to correct anything here that is just wrong…we’re definitely going by observation/experimentation for a lot of this, rather than knowing 100% how it’s intended to function. So there definitely could be some incorrect conclusions or assumptions!)