[bug] conan 1.42.0: CMakeDeps does not inherit anymore from cmake_find_package_multi names

Environment Details (include every applicable attribute)

• Operating System+version: macOS Big Sur
• Compiler+version: Apple Clang 13
• Conan version: 1.42.0
• Python version: 3.9.7

Steps to reproduce (Include if Applicable)

• create a recipe where self.cpp_info.names["cmake_find_package_multi"] in package_info() has a different name than recipe name (a simple one is utfcpp recipe).
• consume this recipe in a project and use CMakeDeps generator (you can replace cmake_find_package_multi by CMakeDeps in test_package of utfcpp recipe and run conan create).

=> generated config file and target will have default value (recipe name), so find_package() and target_link_libraries() might fail.

It has been seen in https://github.com/conan-io/conan-center-index/issues/7887

Workaround: migrate to set_property() (which has an unwanted side effect in CONAN_PKG targets of cmake generator: https://github.com/conan-io/conan-center-index/issues/7925, so the combination of those 2 issues is really annoying).

[SpaceIm]

Ok. Therefore I believe that:

• CMakeDeps shouldn’t be promoted by conan team (in tutorials, and Slack/reddit etc) until CCI recipes properly support it. CMakeToolchain + cmake_find_package* is the way to go currently.
• Transition to set_property() in CCI (and therefore proper support of CMakeDeps) should begin when set_property() is stable enough. CMakeDeps shouldn’t be recommended for consumers until the end of this transition.

[KerstinKeller]

I guess what @SpaceIm means is that if you lowercase the config file

touch xyz-config.cmake

then all of

cmake_minimum_required(VERSION 2.8)
project(xxx)
find_package(XYZ CONFIG REQUIRED)
find_package(Xyz CONFIG REQUIRED)
find_package(xyz CONFIG REQUIRED)

should now work on all platforms.