Issue with dependencies propagation when different versions are present

This question is a consequence of this other one

I’m writing a static library MyLib which I properly package to be found with find_package.
This lib is privately linking another one ThirdPartyLib which is also detected by a find_package command and exports ThirdPartyLib::ThirdPartyLib.

I’m building an executable MyExe that is privately linking MyLib.

Yet, as seen in the linked question, ThirdPartyLib is existing in two flavors on my system:

  • a msvc compliant version
  • a msys2/gcc compliant version

When using MSVC, MyLib is correctly compiling, as its unit tests, that are running fine (these are also executable that are linking MyLib after a find_package. But when I’m trying to build MyExe, the linker is complaining that ThirdPartyLib symbols are undefined.

Looking at the build command created by CMake, I see that it is trying to link the msys2/gcc version, which is, of course wrong.

Looking at MyLib cmake configuration file I only see LINK_ONLY:ThirdPartyLib::ThirdPartyLib without any references to the actual library directories.

I suspect that my unit tests are working because they are using a cmake code that checks the presence of ThirdPartyLib and does “black magic” according to the actual compiler used.

I don’t understand how to fix it. I naively thought that when I declared a dependency, it’s path were registered also. It seems that it is not the case and it looks like LINK_ONLY:ThirdPartyLib::ThirdPartyLib triggers a raw find_package(ThirdPartyLib).

Regards,
A.
[EDIT] a “schematic” to make the issue clearer.
ThirdPartyLib is present as msvc and msys2 versions:
msvc/ThirdPartyLib
msys2/ThirdPartyLib

MyLib private-depends on msvc/ThirdPartyLib
MyExeprivate-depends on MyLib
MyExe is erroneously linked againts msys2/ThirdPartyLib
[EDIT] possible ways to go
1- export in MyLib configuration file the logic to find ThirdPartyLib: don’t know how, risk of conflicting link in case of diamond-like dependency
2- override FindThirdPartyLib system wide: don’t know how, risk of imposing the wrong logic to unrelated projects