상세한 답변 감사합니다. 하긴 근본이 = ㅁ=.. 빌드라서 npm이나 여타 패키지 매니저와 다르게 따라갈 수 없는 벽이 있겠네요. vcpkg는 버전에 관해 고민이 요즘 많아보이는데, 극복하기가 쉽지 않을 것 같군요.
C++20의 모듈 시스템이 이 문제의 해답이 되지 않을까. 싶기도 하지만... 그러면 범위가 C언어를 넘어버리니(...). C언어는 가시밭길밖에 안 남아있겠네요. 이제와서 C20을 제정한다고 하더라도 C++처럼 버전 전환율이 그렇게 높지는 않을거고..
글 쓴 사람입니다(하하...). 현재 사이트는 소프트 릴리스 상태로 실험적으로 글을 작성하고 있는 터라 내용은 지속적으로 수정될 수 있음을 양해 바랍니다. 직접 트래킹도 하고 있지만 이메일로 의견 보내 주시는 것도 받으니 참고해 주세요.
vcpkg는 말씀하신 대로 현재 가장 유망한 패키지 매니저로 보이고, Conan도 사실 꽤 옛날부터 있던 프로젝트입니다(원 작성 시점과 그다지 멀지 않습니다). 하지만 이들 프로젝트의 가장 큰 특징은 스스로는 빌드 시스템이 존재하지 않는 메타 빌드 시스템이라는 것입니다. (주요 지원 타겟인 CMake 자체가 메타 빌드 시스템이라는 걸 생각하면 메타-메타 빌드 시스템일지도...) 따라서 빌드 시스템 자체에서 생기는 문제를 딱히 해결하긴 어렵습니다. vcpkg는 좀 더 고려한 흔적이 보이는데, 예를 들어서 같은 의존성의 다른 버전이 (서로 다른 의존성 경로를 통해) 한 프로젝트에서 필요할 경우 enlistment를 쪼개는 것이 가능합니다만, 이건 빌드 시스템 자체의 한계를 우회하는 방법에 지나지 않지요. 이를테면 Rust와 Cargo는 이 경우 두 버전 모두 빌드해서 한 crate에서 참조하는 데 지장이 없습니다.
또한 vcpkg는 현재 Visual Studio에서는 NuGet 수준의 도구 통합조차 되어 있지 않은 것 같고(오로지 MSBuild 통합만...), 리눅스/BSD 배포판의 패키지 관리자와의 통합도 그다지 되어 있지 않은 것 같습니다. 이 문제는 현재 언어별 패키지 매니저가 직면한 가장 큰 문제이기도 한데 Rust 같은 신생 언어들은 각개격파해서 해결하고 있습니다만, C/C++ 패키지 매니저라면 무조건 기존 시스템과의 통합을 지향해야 할 것인데 그게 아직 지지부진합니다. 이 부분이 해결되고 나서야 비로소 vcpkg 류가 C/C++ 개발에서 보편적으로 사용 가능한 도구가 되었다 할 수 있을 것입니다. 그렇지 않은 것이 제가 글에서 패키지 시스템을 저평가한 주된 이유입니다. (글에서 제시한 single-file library의 범람 또한 vcpkg 류의 시스템이 그렇게 어필하지 못하고 있다는 간접적인 증거이기도 하죠.)