This is a gross misunderstanding and misrepresentation of CMake.

You lead with this, but all I see in your reply is an explanation of why it works exactly the way I described. That explanation apparently it is: "because not everyone in the ecosystem acts the way CMake developers would want them to", which I read as "CMakes design for external dependencies is broken." The fact is, where we are right now, today, the find_package/config script design in CMake frequently makes resolving external dependencies far more painful than it already is without that complication.

That sounds like a lot of repetitive work, doesn't it? So why not provide CMake-provided scripts with the distribution?

I believe my previous reply gives a very clearly answer: because we get stuck in a situation with multiple competing providers of 'scripts' that compete against each other and may apparently all change in backwards breaking ways between releases of CMake, releases of the library in question, and releases of package managers like vcpkg who have taken on themselves to fill in missing scripts.

In the end, it is me who have to dig deep into someone else's mess of CMakeLists.txt:s to try to unravel the mystery of what feature identifiers they expect from that external depedency and how they expect them to work in the find_package/config script the developers happened to use at the time, so I can then go on an archaeological expedition through all possible providers of that config - including older versions of CMake itself to track it down. Multiply with the number of dependencies - which sometimes is up in the hundreds - and it should be clear why this is a horrible, horrible design of a build system.

If we had to stay with CMake's broken design for this, at the very least it would need some form of declaration of dependency config scripts with a provider name and a semantic version. That way the problem would at least be solvable.

However, it is more or less only CMake that has this issue in its attempt to be so 'meta' about everything. Libraries already come with a build-system independent way to specify features: they are split over several library files and software using that dependency choose which ones to link with - using file names. This works well in nearly every other build system. I don't get the motivation to try to abstract this into an interface that (for the reasons we've discussed above) introduces another intermediate dependency layer.

If the worst point you can make about CMake is the cmake config scripts it bundles, then I'm afraid you are very opinionated over irrelevant details that are immaterial to the discussion.

IMO the main task of a build system is to manage inter- and intradependencies to build the software correctly. So, to me, this failure is truly a fundamental strike against it. If I cannot build your software because I cannot sort out your undeclared, unversioned implicit 'config' dependencies, I don't have much use for other features your build system may or may not provide.