Vcpkg install differs from a CMake-based manual install

Vcpkg includes concurrentqueue among its libraries and it installs it - like most of its libraries - through CMake to be consumed also with CMake. The way Vcpkg has client CMake scripts use the library is the following

find_package(unofficial-concurrentqueue CONFIG REQUIRED)
# ...
target_link_libraries(my_target PRIVATE unofficial::concurrentqueue::concurrentqueue)

It turns out that concurrentqueue has its own CMake support that differs in the naming.

find_package(concurrentqueue CONFIG REQUIRED)
# ...
target_link_libraries(my_target PRIVATE concurrentqueue::concurrentqueue)

I would suggest to correct the Vcpkg port so that it exploits the "official" way to use the library with CMake.
I can address the change in Vcpkg. Is this something desirable for other stakeholders?

NOTE:
The two implementations also differ in the include paths (see issue #391). In this respect I find Vcpkg approach more natural and I would suggest to correct that first, then address the Vcpkg change.

Start by comparing the Vcpkg port's CMake client usage with concurrentqueue's own CMake support, then read issue #391 about the differing include paths. Confirm the desired order with stakeholders before changing the port. Done means the Vcpkg integration follows the agreed CMake package and target naming and handles the include paths consistently.