vcpkg was dead in the water because they altered source packages. Completely unacceptable in many situations.
Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds.
Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed.
Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again.
But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed.
Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.