Context

tl;dr;: preserving the previous behavior, and hidden the improvemnet behind opt-in

The newly added MSB3002 ('Explicitly set culture ... was overwritten') is a diagnostic informing about a real problem but it has a potential of breaking a build with esoteric conditions where users might not care about their build behaving wrong.

This was e.g. case solved as part #11091 - where a custom injected target was postprocessing WithCulture metadata after AssignCulture task run. The newly added beahvior broke the task (while adding RespectAlreadyAssignedItemCulture fixed the case - it needed an action from the build owner).

Another case was breakage in dotnet/sdk#45880 - where the test explicitly counted on failing on 'error MSB3030: Could not copy the file "<...>.resources.dll" because it was not found.', while the new behavior lead to success build with warning.

While both cases are quite edgy - it shows the change has potential to break.

Suggestion

Hide the improved behavior behind explicit opt-in

The other options:

• Leave it as opt-out, with warning, while behavior unchanges (the explicit Culture metadata would be overwritten by extension derived culture)
• Leave it as opt-out without warning, while changing beahivor (explicit Culture metada would be always respectd)

Those two are not recommended as they have higher potential of back compat breakages