I will be a bit cynical for a bit.

There isn't anything in C++ as a language preventing us from having a good PDM.

Of course, the preprocessor completely undermines that observation, but the preprocessor is not part of C++. 

And that' s why we may fail to come up with a good dependency manager.

Not just because of the preprocessor, but because having a universal tool will require strong constraints on what a project can do in its build system.

We need to take away freedom. 

We need to limit the number of compiler flags a library can use and impose to others, we need to limit the number of ways a given source file can be expressed.

It's the only way to have a system of manageable complexity with a manageable numbers of unsolvable dependencies.

And we will shy away from that.

The only way to have a large number of libraries that one can include in their projects from the same place, with the same straight forward workflow is to have those libraries play by the same rules.

Other tools in other language impose those rules, they have limited abilities. Yet they are powerful enough that everybody use those tool with great effects.

But those tools were there from the start, so, the code was made with these tools in mind.

There is something to be said for monolithic ecosystems.

From a user perspective, to install the package `foo` maybe they need to type a command or maybe the build system will do that for them. 

If the command does not exist on the system, we failed.

If the correct command is not identical to the one indicated in the documentation of the project, we failed. If that documentation is longer than exactly one line in most cases, we failed, if the build system does not support it, we failed.

(imagine : vcpkg get bar/foo / xcode-cpp-fetch  baz.com/bar:foo / iso-get --from baz.com --org bar --import=export --package foo@version:<auto last> ) 

And, if there is anyway `foo` can resolve to different projects, we failed.

Monolithic systems also exist because there is a need for "dependency foo" to have exactly one meaning.

Doing a dependency manager is hard but as you said, it's a solved problem. Doing one able to handle the existing code may not be. It's harder. Maybe not solvable. Is it worth trying ? I don't know.

Like Titus said, people need too learn what a well behaved dependency is.

But if we decide to have an idealistic approach, will people adopt that new tool/protocol/standard ? Nobody like dealing with build systems, and whatever crappy CMake scripts they have today "works" - well, they think they do.

Rust, for example did not endure 30 years of complete wild west jungle mess before offering those tools, that's the difference.

Likewise, I'm doubtful that anyone in those communities would be successful in offering an alternative solution to their idiomatic tools.

So, really C++ is not the major issue.

The major issue is the amount of C++ libraries out there all with overly complex, non portable build scripts, the unwillingness of their authors to support something new or their lack of resources to do so. 

And a package manager without libraries is a bit pointless, isn't it ? Chicken egg problem and all.

(I also tend to think that the publication of a given project in any kind of public repository is best left to their author, rather than a third party packager as that weakens the trust in the dependencies)