This is related to the discussion of MC-196614. I want to point out here that the stripping of uninitialized lightmaps, as discussed in MC-196614, already causes issues on its own without relying on MC-196614, i.e., queued lightmaps being ignored for lightmap initialization.
I put this here mainly for reference. Similarly to MC-196614 this is automatically fixed by my proposed solution to MC-196725.

 
Consider a similar setup as in the other report:

• Create a redstone-ready world with generator settings 16*minecraft:sandstone;minecraft:desert
• Set the render distance to 2
• Run the following commands

  /setworldspawn 1000 16 1000
  /fill -15 32 -15 63 32 63 minecraft:sandstone
  /fill 16 32 16 31 32 31 minecraft:air
  /fill 16 1 16 31 15 31 minecraft:stone
  /fill 0 0 0 47 7 47 minecraft:air replace minecraft:sandstone
  /fill 0 8 0 47 15 47 minecraft:air replace minecraft:sandstone
  

• Fly to chunk (-14 1)
• Fly back to chunk (1 1) and observe that subchunk (1 0 1) is fully bright (The other broken lightmaps are instances of MC-196614 and can be ignored for this discussion)

Upon saving chunk (1 1) the lightmap at (1 0 1) gets stripped is at was uninitialized. Upon reloading it gets "correctly" (in comparison to MC-196614) initialized by inheriting the values from the lightmap directly above it.
The issue in this case is that the lightmap should not have been initialized by inheriting values from above in the first place, but it should have been left uninitialized.
One could now patch this specific case by not initializing lightmaps for non-empty subchunks, at least during loading.

However, there are more subtle cases that show that there is in general no easy way to hackfix this issue:

• Create a redstone-ready world with generator settings 33*minecraft:sandstone;minecraft:desert
• Set the render distance to 2
• Run the following commands

  /setworldspawn 1000 16 1000
  /fill 0 0 0 31 15 47 minecraft:air
  /fill 0 16 0 31 31 47 minecraft:air
  /fill 32 16 0 47 31 47 minecraft:air
  /fill 45 32 16 45 32 31 minecraft:air
  

• Fly to chunk (-14 1) and back to chunk (-2 1)
• /setblock 8 8 8 minecraft:sandstone
• Fly back to subchunk (1 0 1) and observe that the blocks at the boundary to subchunk (2 0 1) have a light value of 1 instead of 0.

Again, upon saving the uninitialized lightmap at (1 0 1) is stripped. When placing the block at (8 8 8) it is regenerated and "correctly" (in comparison to MC-196614) inherits its value from the lightmap above. And again the lightmap should have been left uninitialized instead of inheriting from the lightmap above.

A conflict now arises with the following variation:

• In the initial block of commands, additionally /fill 32 0 0 47 15 47 minecraft:air
  This additionally clears the remaining subchunks (2 0 0) .. (2 1 2).
• This time the lightmap at (1 0 1) gets removed because there are no nearby non-empty subchunks
• When placing the block at (8 8 8) the lightmap at (1 0 1) needs to be regenerated again, but this time the correct value is indeed by inheriting from above.
• The only difference to the previous example lies in the chunks (2 0) .. (2 2) which are not loaded at the time the lightmap is generated. But the correct result is different from the previous example.

This shows that stripping uninitialized lightmaps really incurs a data loss that cannot be repaired easily.

Similar to the discussion of MC-196614, you should not simply remove the stripping of uninitialized lightmaps, as this will lead to a "massive" increase in memory usage for lightmaps. Instead this issue should be fixed via my proposed solution for MC-196725.

Also, when implementing my proposed fix for MC-196725, old worlds should be forced to relight once in order to account for the missing data discussed here, rather than trying to somehow partially recover the missing data from broken old saves.

Best,
PhiPro