I second that.
in fact you can update one probe at a time every frame or every X seconds (you can already do that with a custom C++ class, without modifying the engine code).
they could go even further and subdivide the probe capturing function so that its routine is done over multiple frames, so that the engine, every frame, does a tiny bit of processing to recapture the probes little by little but continuously. this would lead to a low-impact solution that guarantees everything will be updated at least every X seconds.
to make it a bit more precise the probes could be updated more or less frequently based on a priority, which would be defined by how close the probe is to the player.
all this would allow dynamically changing lighting (i.e. time of the day) with even a changing skylight capture, as well as lighting that changes based on whatever happens in the game (drastically changing weather, closing all windows in a room, starting a fire in a city, generating new geometry, etc).
I think an extra option wouldn’t hurt, and then it’d be up to everyone to decide which system to use (just like right now you can decide between lightmass, LPV, DFGI or nvidia’s VXGI)
it wasn’t really a dynamic effect because the lighting was static. what the LightEnvironment system did was that, when you bake the lightmass, it would create small probes of captured light scattered in a grid in 3D space (only inside the LightmassImportanceVolume). the dynamic part was only that when an object moves it would get the nearest probe so it’d always have its lightint matching the surrounding environment.
but moving a light or recapturing these probes was never supported.
also I’m pretty sure UE4 uses the same system when lightmass is used