Performing major upgrade from installed Wix3 bundle to new Wix4 bundle

[lukeskrz]

We recently upgraded our Wix3-based installer to Wix 4.0.1. The installer is an exe bootstrapper bundle wrapping two MSIs (one 64-bit, one 32-bit).
The new Wix4 installer seems to work as expected, except when it comes to major upgrades.

If I have our old Wix3 based version installed, and run the Wix4 bundle then it detects the related bundle, but not the MSI package. I believe this prevents the WIX_UPGRADE_DETECTED property from being correctly populated, which causes logic issues in our MSI (as it's acting as a fresh install instead of an upgrade)

We are using the same upgrade code, and ProviderKey as before. The 3rd number in the version string is being incremented, and a ProductCode is not defined.
Major upgrades previously worked as expected between Wix3-based versions of our product, so it seems that something might have changed with Wix4.
Is there some additional step that needs to be taken to get this working?

Here is a section of our bootstrapper logs. It detects the old installed version 23.7.7.0, but both of the relevant MSIs (SFWindows64_msi, and SFWindows_msi,) are marked as having an "Absent" state.

[01B4:49CC][2023-07-17T15:59:14]i100: Detect begin, 5 packages
[01B4:49CC][2023-07-17T15:59:14]i000: Setting string variable 'NETFRAMEWORK45' to value '533320'
[01B4:49CC][2023-07-17T15:59:14]i110: Detected bundle provider key: {EAFC01E2-1320-497C-BCEE-5F0A0CF284B8} that is registered to a different bundle: {96E1CC59-41D7-4C4B-925A-ABECCC8DE1DD}
[01B4:49CC][2023-07-17T15:59:14]i102: Detected related bundle: {8675c2a7-fc87-4a20-815e-356dc7732717}, type: Upgrade, scope: PerMachine, version: 23.7.7.0, cached: Yes
[01B4:49CC][2023-07-17T15:59:14]i052: Condition 'NETFRAMEWORK45 >= 394802' evaluates to true.
[01B4:49CC][2023-07-17T15:59:14]i101: Detected package: NetFx462Web, state: Present, cached: No, install registration state: (permanent), cache registration state: (permanent)
[01B4:49CC][2023-07-17T15:59:14]i101: Detected package: WinFsp_patch, state: Absent, cached: No, install registration state: Absent, cache registration state: Absent
[01B4:49CC][2023-07-17T15:59:14]i101: Detected package: WinFsp_msi, state: Absent, cached: No, install registration state: Absent, cache registration state: Absent
[01B4:49CC][2023-07-17T15:59:14]i101: Detected package: SFWindows_msi, state: Absent, cached: No, install registration state: Absent, cache registration state: Absent
[01B4:49CC][2023-07-17T15:59:14]i101: Detected package: SFWindows64_msi, state: Absent, cached: No, install registration state: Absent, cache registration state: Absent
[01B4:49CC][2023-07-17T15:59:14]i199: Detect complete, result: 0x0, registration state: None, cached: No, eligible for cleanup: No

[lukeskrz]

This seemed to be a difference between Wix3 and Wix4 in how it handles the Language attribute defined on the Package element in our MSI.
Wix4 appears to use this value in the Language column of the Upgrade table in the resulting msi. Previously, it seems like Wix3 left this column blank.
Thus the new Wix4 msi wasn't recognizing the previous Wix3 msi as a related product due to the language code mismatch.
Removing the explicit language code from our new Wix4-generated msi caused the upgrades to start working again as expected.