[BreezeDelegate]

Summary

When one version of an application is removed while another version with the same normalized product name remains installed, shared leftovers can still score as Good and be selected by default.

For Blender 4.4 / 4.2, the remaining Blender entry is intentionally filtered out by the existing similar-name logic because both versions normalize to Blender. That leaves both the shared %AppData%\Blender Foundation\Blender node and, depending on the directory contents, its Blender Foundation parent eligible for default selection.

This change treats product- and publisher-named heuristic leftovers as shared when another installed entry has the exact same normalized product name. Version-specific leftovers remain unchanged.

The console cleanup path now also passes the full remaining application inventory to the junk scanners instead of only the selected uninstall targets. This preserves the same safety model when one version remains installed, while avoiding false protection when both versions were successfully removed.

Fixes #758.

Validation

• current master (30da609): the reported Blender settings node reproduces at raw confidence 4 / Good
• adversarial follow-up: the Blender Foundation parent also reproduced at Good before the final fix
• reviewer follow-up: an explicit InstallDir registry match reproduced at raw confidence 8, then remained raw 5 / VeryGood with the first penalty; the adjustment now leaves it raw 1 / Questionable while Blender 4.2 remains installed
• second reviewer follow-up: with a publisher that does not contain the product name, the same registry shape reproduced at raw 10 and the fixed -7 penalty left it raw 3 / Good; the adjustment now expands only when necessary so shared generic leftovers are capped at raw 1 / Questionable
• focused source harness verifies both explicit-registry cases, while version-specific junk and the no-remaining-version path keep their original confidence unchanged
• after a real uninstall, the console refreshes the installed-application inventory before junk scanning, so Store/Steam and other non-registry entries are represented by their current factory state
• all seven focused MSTest regression cases compile in BulkCrapUninstallerTests
• BCU-console builds with 0 warnings / 0 errors on .NET 8
• BulkCrapUninstallerTests builds with 0 errors; the 34 CS0436 warnings in the Linux build are identical to clean master
• Linux validation replaces only the Windows COM Scripting reference with a disposable build stub; it is not part of the PR
• the native MSTest host cannot execute on this Linux validation host because Microsoft.WindowsDesktop.App is unavailable; the focused harness executes the actual confidence source files instead
• git diff --check clean

[jad-fahmi]

I may be missing another confidence adjustment, but a Blender key below Blender Foundation with InstallDir pointing to version 4.4 can still score 5 (VeryGood) after this -3 record. Could the regression cover this case and confirm the shared key falls below the default-selection threshold while version 4.2 remains installed?

[BreezeDelegate]

Good catch. I reproduced that exact shape: the explicit InstallDir match started at raw 8 and the first -3 adjustment still left it at raw 5 / VeryGood.

I strengthened the same-product adjustment and added a regression for the explicit registry case. It now lands at raw 1 / Questionable while Blender 4.2 remains installed. Version-specific Blender 4.4 junk is still left alone.

[jad-fahmi]

SoftwareRegKeyScanner still gives a shared key raw 3 / Good after the -7 adjustment when the publisher name doesn’t contain the product name. Could you add a regression for this case and verify the key stays below Good while another version remains installed?

[BreezeDelegate]

You were right again. With a publisher that doesn't contain the product name, I reproduced raw 10 before the same-product adjustment, so the fixed -7 penalty left the key at raw 3 / Good.

I added that regression and changed the adjustment to keep the existing -7 minimum while extending it only when needed to cap shared generic leftovers at raw 1 / Questionable. The control cases still behave the same: version-specific junk is unchanged, and no penalty is applied when no same-product version remains installed.

[jad-fahmi]

Would it make sense to keep still-installed Store and Steam entries when building remainingApps? Their factory-created entries have no RegistryPath, so RegKeyStillExists() filters them out even when their InstallLocation still exists. The cleanup scan then cannot consider their use of shared leftovers.

[BreezeDelegate]

Yes. Rather than special-case Store and Steam with InstallLocation, I changed the real-uninstall path to refresh the application inventory before the junk scan.

That way Store, Steam, and other non-registry sources are represented by their current factory state instead of being filtered through RegistryPath. Dry-run still uses the original inventory because nothing was actually removed.