`PATH` variable eventually becomes too long when installing many CLI apps

Description of the new feature / enhancement

Summary

Currently, many CLI packages tend to modify the user PATH variable to make its binaries available in the shell. This is totally fine. However, as the user installs more CLI apps[^1], the PATH variable becomes so crowded that it exceeds Windows' default 2048-character limit.

[^1]: As is typically the case for many developer workflows.

Additional Context

Normally, this is not an issue because some programs just sweep the limit under the rug. However, I report this issue now because I did encounter an issue with Goneovim where it always crashes on startup. A "little" investigation with the --debug logs led me to the conclusion that the nvim executable could not be found in the PATH.

This baffled me because I was sure I had it in there. Sure enough, the Neovim's bin folder was in the PATH. It seemingly turns out that either Goneovim or Qt (i.e., the UI framework on which Goneovim is built) mishandles PATH variables whose lengths are greater than 2048. I have not sufficiently investigated where the issue is, but once I shortened the PATH, my problem was resolved.

Now, I know that this is technically an issue with Goneovim and Qt, but I figured to tackle the root of the issue instead: the excessively long PATH variable (hence filing this issue).

Proposed technical implementation details

Problem

When Winget installs CLI apps, some packages modify the PATH variable such that Winget appends the following entry: %LOCALAPPDATA%\Microsoft\WinGet\Packages\<package>_Microsoft.Winget.Source_8wekyb3d8bbwe. Even without substituting the %LOCALAPPDATA% variable, observe that the entry is already quite verbose for a PATH entry.

Now multiply this by the number of CLI apps that need to be installed. The bytes quickly add up!

Prior Art of a Possible Solution

Other package managers such as Chocolatey and Scoop work around this issue by automatically generating thin "shims" in a common bin-like folder (i.e., C:\ProgramData\chocolatey\bin and %USERPROFILE%\scoop\shims, respectively). Then, this folder is the only one added to the PATH variable.

Pros: we only add one entry to the PATH. New installations only need to generate a shim into the bin-like folder for it to be made available to the shell.

Cons: shim synchronization may be an issue. There are more points of failure in the indirection, which may introduce more bugs. In my experience with Chocolatey and Scoop, however, these have never been an issue.

No files or tests are named. Start by locating the WinGet CLI code that installs packages and updates PATH, then compare how Chocolatey and Scoop generate shims. Done should mean installed CLI apps are reachable through one common PATH entry without adding a separate long package path for each installation.