FetchContent population reuse semantics when re-entering a superbuild from a different directory scope

Context

FetchContent is documented to populate external sources once per build tree, caching the result under the build directory and reusing it on subsequent configures unless the declared URL, URL_HASH, or content changes. This contract works predictably for a single top-level configure run.

Ambiguity

When a superbuild re-enters its own CMake logic from a different directory scope — for example, a nested add_subdirectory that re-invokes FetchContent_MakeAvailable for the same declared dependency — the cache invalidation rules become unclear. The populated source directory exists, but the module may re-evaluate the declare step in a new scope, potentially triggering a second population or skipping it silently depending on CMake version and policy settings (e.g., CMP0145). Multi-config generators and partial build-tree cleans add further variance.

Goal

Determine whether FetchContent guarantees idempotent reuse across re-configure entry points in different directory scopes, or whether the population step can run again and under what exact conditions.

• Does the cache key incorporate the calling directory scope, or is it purely based on the declared content identifiers?
• Which CMake policies or version thresholds change the reuse behavior for nested superbuild entry points?
• Is there a documented way to force or suppress re-population without altering URL_HASH?