Can an imported target retain mixed CMake policy semantics across directories?

Short answer

No. CMake does not attach policy state to an imported target. An imported target's properties are recorded when the target is created, but policy-sensitive behavior is governed by the policy active in the directory where the consuming command runs. One imported target cannot silently apply OLD semantics in one directory and NEW semantics in another within the same build tree.

Confirmed behavior

• Policies are directory-scoped. A cmake_policy(SET ...) call affects the current directory and directories added afterward.
• Imported targets are ordinary targets in CMake's model. Once created, their stored properties such as INTERFACE_LINK_LIBRARIES are not re-evaluated under a new policy merely because a subdirectory changes the policy.
• There is no supported mechanism to bind an imported target to the policy state of its defining directory.

What happens in your layout

1. The top-level CMakeLists.txt creates the imported target under the top-level policy set.
2. The subdirectory changes the policy with cmake_policy(SET CMPXXXX OLD).
3. When that subdirectory links the imported target, the link operation uses the subdirectory's active policy. The imported target itself does not carry a snapshot of the top-level policy.

Recommended steps

1. Decide which policy should govern each link site and set it immediately before the target_link_libraries call, using cmake_policy(PUSH) and cmake_policy(POP) if you need to restore the previous state.
2. Do not rely on an imported target created in one directory to enforce a different policy in a child directory.
3. If consistent behavior is required across directories, keep the policy unchanged between target creation and consumption, or recreate or wrap the imported target in each directory under the intended policy.

Verification

Run these scoped commands in a clean build tree and inspect output:

cmake_minimum_required(VERSION 3.15)
project(policy_probe)

add_library(probe_imported IMPORTED INTERFACE)
set_target_properties(probe_imported PROPERTIES INTERFACE_LINK_LIBRARIES "example_lib")

add_subdirectory(sub)

In sub/CMakeLists.txt, set the policy, link the target, then print the stored property:

cmake_policy(PUSH)
cmake_policy(SET CMPXXXX OLD)

add_executable(probe_app main.cpp)
target_link_libraries(probe_app PRIVATE probe_imported)

get_target_property(_props probe_imported INTERFACE_LINK_LIBRARIES)
message(STATUS "imported property: ${_props}")

cmake_policy(POP)

Confirm which policy governed the link by checking the link command in the build output (for example, make VERBOSE=1 or the equivalent for your generator). The property value itself will not reveal the active policy; only the generated link rule will.

Missing diagnostic detail

Which exact policy ID and CMake version are involved? Policy defaults and inheritance details can differ between releases, so this determines whether a version-specific workaround is needed.

Note: this draft relies on documented CMake directory-scoping behavior. Because the research flagged version sensitivity, treat it as ready for human review until verified against your CMake version.