Microsoft Update detects the installed 7.6.5 and offers nothing, or offers only a genuinely
newer build.

MU offers three PowerShell packages at once, including the exact version already installed:

    PowerShell v7.3.1 (x64)
    PowerShell v7.6.3 (x64)
    PowerShell v7.6.5 (x64)

7.6.3 and 7.3.1 fail on install. The offers return on every subsequent scan regardless of
outcome, including after a successful install.

Creating a directory junction at the default install path makes all three disappear on the
very next scan:

    mklink /J "C:\Program Files\PowerShell\7" "X:\Program Files\PowerShell-7-x64\7"

Nothing else changed between the two scans. This suggests MU detection probes a hard-coded
default path rather than reading HKLM\SOFTWARE\Microsoft\PowerShellCore\InstalledVersions or
the Windows Installer product registration, both of which were present and correct throughout.

Install failures:
    PowerShell v7.6.3 (x64)  -  0x80070643
    PowerShell v7.3.1 (x64)  -  0x8024200b

This is a detection failure, not supersedence (as postulated in possibly related issue #26046). 

Three points:

1. The already-installed version is offered. 7.6.5 was offered alongside the older builds
   while 7.6.5 was installed and correctly registered. No supersedence rule explains offering
   a package identical to what is installed. MU appears to conclude PowerShell is absent, so
   the catalog offers everything.

2. Installing an offered build does not stop it being re-offered. Update history shows 7.6.3
   installing successfully, then 7.6.5 74 seconds later, also successful:

       8/17/2026 10:50:52 PM   PowerShell v7.6.3 (x64)   ResultCode 2 (Succeeded)
       8/17/2026 10:52:06 PM   PowerShell v7.6.5 (x64)   ResultCode 2 (Succeeded)

   7.6.3 was offered again ten days later.

3. The MSI registration is healthy:

       ProductCode  : {499CA787-2899-40D2-A793-087E08EB227D}
       Name         : PowerShell 7-x64
       Version      : 7.6.5.0
       LocalPackage : C:\Windows\Installer\1485d9e1.msi
       CacheExists  : True

   HKLM\SOFTWARE\Microsoft\PowerShellCore\InstalledVersions is also correct:

       31ab5147-9a97-4452-8443-d9709f0516e1   7.6.5   X:\Program Files\PowerShell-7-x64\7\

   No orphaned product registrations, no dangling upgrade-code mappings. Reinstalling with
   REINSTALL=ALL REINSTALLMODE=vomus completes with "MainEngineThread is returning 0".

Ruled out:
- Standard WU remediation (stop wuauserv/cryptsvc, delete SoftwareDistribution and catroot2,
  SFC, DISM) has no effect.
- USE_MU=0 ENABLE_MU=0 applies cleanly, confirmed in the verbose log property table, and
  changes nothing. That property governs whether PowerShell registers for MU servicing, not
  whether MU can detect the install.

Suggested fixes:
- Have the MU applicability rules read PowerShellCore\InstalledVersions or the MSI product
  registration instead of probing a fixed filesystem path.
- Populate ARPINSTALLLOCATION from INSTALLFOLDER. InstallLocation is currently empty in
  Installer\UserData\...\InstallProperties and ARPINSTALLLOCATION never appears in a verbose
  install log. This one is entirely within the MSI's control.
- At minimum, document that INSTALLFOLDER is incompatible with Microsoft Update servicing.

I recognise the applicability rules are published service-side and may not be owned by this
repo. Happy to be redirected, but the ARPINSTALLLOCATION gap and the undocumented
INSTALLFOLDER incompatibility are MSI-side.

Possibly related to #26046, though that report appears to involve a default install path, so
the mechanism may differ.