Since CMake 3.3, on Windows, the `find_path`, `find_file`, and `find_library` commands compute search prefixes from the `PATH` entries of the form `$prefix/bin`. The change was made by commit ffc06c12397e7cda7307afcfc8a79ebda4a786a6 for #15370, and was originally made for all platforms. CMake 3.6 reverted it for non-Windows platforms in commit b30b32a4931080280680aa5b439c0d4918553c56 due to finding shared libraries in undesired prefixes. However, the justification for to retain the behavior on Windows was stated in the commit message: > The motivation was to support MSYS, MinGW and similar Windows platforms in their default environments automatically. The idea is that on Windows one typically sets `PATH` as part of establishing specific development environments, so we might as well use that information to automatically find libraries and headers for the target environment. Recently, !7694 taught `find_library` to search for the `libfoo.a` naming convention even for the MSVC ABI, for #23975. However, that regressed existing build environments as reported in https://gitlab.kitware.com/cmake/cmake/-/issues/23975#note_1280921 and #24168. Discussion in #24168 identified that `find_path` had already been finding MinGW headers even when using MSVC, but they previously went unused by luck because `find_library` was not finding the corresponding MinGW library prior to considering the `libfoo.a` naming convention. **The problems encountered with searching for the `libfoo.a` naming convention were not inherent, but were due to searching MinGW prefixes even when using MSVC, because they were derived from the `PATH`.** !7962 resolved the regressions for the 3.25 series by reverting the change, but both issues' discussions identified more **general problems with searching `PATH`-derived prefixes**. They are very similar to the reasons CMake 3.6 reverted the behavior on non-Windows systems. I'm opening this issue to **propose dropping that behavior** on Windows too, and to discuss alternative ways to find MSYS and MinGW packages in their respective development environments without using `PATH` to derive search prefixes in general.