Without opening a question of dropping support for older CMake versions, additional requirements apply for the DLL naming:

• Users can use the built-in FindBoost.cmake module in CMake Version 3.10: https://github.com/Kitware/CMake/blob/v3.10.0/Modules/FindBoost.cmake
• Users can use the built-in FindBoost.cmake module in CMake Version 3.11: https://github.com/Kitware/CMake/blob/v3.11.0/Modules/FindBoost.cmake
• Users can use the built-in FindBoost.cmake module in CMake Version 3.24.3 (latest): https://github.com/Kitware/CMake/blob/v3.24.3/Modules/FindBoost.cmake
• Users of newer MSVC toolsets (e.g. v143) MUST be able to find and link against Boost binaries built with older MSVC (e.g. v140)
• Users must find Release and Debug files correctly for multi-config generators
• Users must find static or dynamic libraries based on the vcpkg build settings

All of the above must work out of the box without any user customization

Users of newer MSVC toolsets (e.g. v143) MUST be able to find and link against Boost binaries built with older MSVC (e.g. v140)

Do you now which CMake version VS shipped with for VS 2022; 2019 and 2017 ?

apply for the DLL naming:

you mean LIB naming. vcpkg doesn't touch the dlls.

Users can use the built-in FindBoost.cmake module in CMake Version 3.10:
Users can use the built-in FindBoost.cmake module in CMake Version 3.11:

if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.10)
      set(_boost_COMPILER "-vc141;-vc140")
    elseif (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19)
      set(_boost_COMPILER "-vc140")

vcpkg shouldn't support FindBoost with VS 2022 and e.g. CMake 3.10. (VS 2022 was only added in 3.21). This means max VS 2017 which is full filled by FindBoost . But the upstream model only supports boost up to 1.71 in 3.11 so maybe drop that requirement since it is unrealistic considering boost in vcpkg is at 1.80 and would logically require a newer CMake anyway (since vcpkg removes the version from the libs files it will probably find it regardless.).

Users can use the built-in FindBoost.cmake module in CMake Version 3.24.3 (latest):

that is nearly tested by CI using it. (Increase CI CMake to match latest CMake? Or is that good enough?)

Users of newer MSVC toolsets (e.g. v143) MUST be able to find and link against Boost binaries built with older MSVC (e.g. v140)

that should be handled by https://github.com/Kitware/CMake/blob/c974557598645360fbabac71352b083117e3cc17/Modules/FindBoost.cmake#L879-L881

Users must find Release and Debug files correctly for multi-config generators

only relevant change considering that is:
set(BOOST_LIB_DEBUG_SUFFIX .lib) # Note: FindBoost.cmake will not look for d suffixed libraries
I can make that case an error instead since that case should never happen anyway.
All other code paths don't change the behavior.

Users must find static or dynamic libraries based on the vcpkg build settings

there is no change in this PR which would change that

First I want to clarify that I was not attempting to only list items I believed this PR would break. This (renaming boost libs) has often been a topic of discussion before (as you listed -- "leads to irritation about the lib name") and so I wanted to provide a more complete picture of what our requirements are.

Do you now which CMake version VS shipped with for VS 2022; 2019 and 2017 ?

The last VS2017 ships with 3.12 (thanks @BillyONeal for installing it in a VM and checking!), however the existing comments[1] clearly indicate an intent to work with 3.10 or below. That's why I started with "Without opening a question of dropping support for older CMake versions" -- the current implementation claims support for at "least" 3.10, so dropping that would clearly be a changed support intent.

But the upstream model only supports boost up to 1.71...

While CMake's FindBoost module does emit warnings for newer Boost versions, I have personally been extremely successful in the past when using a newer boost than what the CMake version explicitly checked. I believe the two potential issues are 1) new components won't be listable and 2) inter-dependencies with compiled modules may not be accurate. New components are not widespread by definition (they're new) and the inter-dependencies between compiled modules do not change very much from version to version.

that is nearly tested by CI using it. (Increase CI CMake to match latest CMake? Or is that good enough?)

Yep, I think that's good enough. I just wanted to be thorough in my list of "requirements".

that should be handled by https://github.com/Kitware/CMake/blob/c974557598645360fbabac71352b083117e3cc17/Modules/FindBoost.cmake#L879-L881

Those lines were added in CMake 3.15 and so relying on them breaks 3.11 3.12 / 3.10 requirement.
Kitware/CMake@717e854

[1]: string(REPLACE "-x32-" "-" NEW_FILENAME ${NEW_FILENAME}) # To enable CMake 3.10 and earlier to locate the binaries
[2]: https://github.com/Kitware/CMake/blob/v3.10.0/Modules/FindBoost.cmake#L1674

the current implementation claims support for at "least" 3.10, so dropping that would clearly be a changed support intent.

You cannot use vs142/3 with CMake 3.10 so there is no need to support that "use case" since it doesn't exist. Support for 3.10 is only given for VS2015/17.

Those lines were added in CMake 3.15 and so relying on them breaks 3.11 3.12 / 3.10 requirement.

being a vs143 user already requires to be a 3.21 user. (https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2017%202022.html)

being a vs142 user requires to be at least a 3.14 user and that was based on a experimental VS release according to the release notes; so I am more in less in line to consider 3.15 the official supported version for vs142 ;). Especially since upstream CMake doesn't touch Find Modules unless stuff has been released (which I learned from trying to update FindMATLAB with a newer version before it was released.)
(https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html)

So the real question here is if VS2019 really shipped with CMake 3.14 on release with an obviously broken FindBoost.cmake for that version.

So I think i solved the CMake FindBoost issue by simply downloading the 3.24.3 version and forcing it via CMAKE_MODULE_PATH.

Hi @Neumann-A, I've taken the liberty of splitting out the has_snchro bits -> #30836. I'll place this PR on draft status until the other PR lands then readdress the lib renaming stuff.

I do apologies for the slow turnaround on this PR.

Discussion is currently in https://github.com/microsoft/vcpkg/pull/27694/files#r1238076280 which isn't directly visible from the main page