winget should not list non-actionable upgrades when no compatible installer candidate exists

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

winget upgrade and winget upgrade --all currently list some packages as having available updates even when no compatible installer candidate actually exists for the installed package.

This is misleading and confusing. From a user perspective, if a package is shown in the normal upgrade list, it implies that the upgrade is actionable.

However, in some cases winget later skips the package during installer selection, for example because:

• the installed package type is incompatible with the available installer type
• locale/applicability filtering leaves no usable installer candidate

As a result, winget presents packages as upgradeable even though they are not actually upgradeable in the current environment.

This should be improved so that the visible upgrade list better reflects what winget can really install.

Proposed technical implementation details

Before showing a package in the normal upgrade results, winget should validate that at least one installer candidate is actually applicable to the currently installed package and current machine context.

That validation should include the same checks that are later used during installer selection, including at least:

• installer type compatibility with the installed package
• locale filtering
• applicability / platform / architecture checks
• other selection rules that can fully eliminate all installer candidates

If no applicable installer candidate remains after those checks, winget should not present the package as a normal available upgrade.

Possible implementation options:

1. Exclude such packages from the standard upgrade list entirely
2. Show them in a separate category, for example:
   • Updates available but not applicable
   • No compatible installer candidate
3. Keep them visible, but print an explicit reason in standard output explaining why they cannot be upgraded

Any of these approaches would be better than the current behavior, where packages appear as normal available upgrades but are silently skipped later.

The key point is that upgrade discovery output should align with actual upgrade feasibility, rather than listing upgrades that are known in advance to be non-actionable.

WinGet-2026-03-06-23-46-31.975.log

Start at the winget upgrade and winget upgrade --all entry points, then trace how upgrade discovery differs from later installer selection. Compare the checks used for installer type, locale, applicability, and platform or architecture filtering. Done means non-actionable packages are excluded, separated, or given an explicit reason rather than silently skipped.