This happened to me when I had a custom UV set on UV1, but had “generate lightmap UVs” UNCHECKED on LOD0, so that the procedural lightmap UVs wouldn’t stomp the custom ones. This is USUALLY okay, but the problem was when importing a custom LOD1 for that mesh.
The fix: Go to LOD Picker>CHECK custom>go to LOD1 (or wherever you have custom LODs)>CHECK “generate lightmap UVs.”>apply changes>lightmap coordinate index = 1 (or wherever you had your custom lightmaps imported).
*Note: This will NOT affect the LOD0’s custom lightmap UVs (which is ideal). You can see if each LOD uses a lightmap UV by enabling the UV dropdown in the static mesh editor window, and selecting each LOD draw in the viewport dropdown.
The other methods of deleting and re-generating LODs is not going to work if you have custom one(s).
You guys were struggling one year with this issue and I figured it out after experimenting for five minutes. 
12/17/20 Update It seems that the coordinate index is still unable to be set, even if the destination lightmap index matches the correct index of the LOD0. For instance, a mesh could have four lightmap sets, and the proper lightmap set is on UV2. If there is no UV3 (the fourth/last lightmap) generated for the custom LOD, then the coordinate index will only let it be set as the current highest amount of whichever LOD has the least amount of UV sets. Thus, the fix is to set the destination lightmap index for each non-existent set on the custom LOD, apply changes, and repeat the process until it has slots for each UV set (as tested by switching the viewport LOD to the custom LOD #, then scrubbing through each UV in the UV dropdown. Then, the higher/proper coordinate index can be set.
