"Future version" will have lots of fanfare before that actually happens. There's no timeline for it; it's a warning that, eventually, we will have to drop old behaviors because otherwise we're stuck with terrible behaviors forever. I mean look at the kinds of things we still support (https://cmake.org/cmake/help/latest/manual/cmake-policies.7....):

- CMP0010 is there to allow projects which did `${var` to "work"; it is an error today
- CMP0038 bans `target_link_libraries(tgt tgt)`
- CMP0053 gives a *much* faster variable expansion engine at the expense of no longer expanding `@var@` in regular CMake code

And it's only with projects using pre-2.8.12 behaviors of policies that actually care about that. If the project is policy-warning clean (except for the policies we cannot realistically warn on, but these are obscure in practice), then you're already compatible. For the record, the old behaviors we cannot warn about because detecting reliance on the old behavior is nigh impossible in practice:

- CMP0025: Xcode's `clang` now reports its compiler id as `AppleClang` (due to different versioning schemes); we cannot track if this behavior is used
- CMP0047: Same thing for `qcc` on QNX to use the `QCC` compiler id
- CMP0056: `try_compile` uses link flags
- CMP0060: obscure Unix platform implicit link directory order shenanigans (HP-UX at least)
- CMP0061: Remove the implicit `-i` flag to `make` when doing `cmake -build`
- CMP0065: executables now need to explicitly export symbols if wanted (was implicit)
- CMP0066: `try_compile` now supports per-config flags (instead of only `CMAKE_<LANG>_FLAGS`)
- CMP0067: `try_compile` forwards language standard flags through
- CMP0073: removal of `_LIB_DEPENDS` cache variables (an implementation detail that got into the cache due to historical decisions)
- CMP0082: install rules now happen in declaration order (used to be depth-first order)
- CMP0088: `FindBISON`'s CMake API now uses `${CMAKE_CURRENT_BINARY_DIR}` instead of the source directory
- CMP0089: compiler id change for IBM's clang-based xlc compilers: `XLClang`
- CMP0090: `export(PACKAGE)` default behavior change
- CMP0091: MSVC runtime flags are now an abstraction (instead of baked into `CMAKE_<LANG>_FLAGS_<CONFIG>`)
- CMP0092: MSVC warning flags are removed from `CMAKE_<LANG>_FLAGS` (to avoid having to `string(REPLACE)` if one wanted to change them)
- CMP0093: `FindBoost` version reporting format
- CMP0094: `FindPython*` search behavior changes (used to prefer the newest Python over a specific one)
- CMP0096: Version numbers with leading zeros are preserved (instead of `21.05` being stripped to `21.5`)
- CMP0097: `ExternalProject` handling of git submodules
- CMP0098: `FindFLEX` change to mirror `FindBISON` above
- CMP0099: link usage interfaces (options, directories, depends) are pushed through linking to static libraries privately (just like linking was)
- CMP0101: `target_compile_options(BEFORE)` works on all visibilities (instead of ignoring it in `PRIVATE`)
- CMP0102: `mark_as_advanced` no longer wrecks havoc with local variables
- CMP0105: link options now apply to the device linking step (CUDA)
- CMP0107: `ALIAS` target cannot shadow existing targets
- CMP0108: rejects `target_link_libraries(tgt alias_of_tgt)`
- CMP0112: relaxes target dependencies when generator expressions are used
- CMP0113: internal Makefiles generator fixes to avoid running custom commands multiple times
- CMP0116: Ninja generator transformation of `add_custom_command(DEPFILE)` contents to match CMake's usage of paths in the `build.ninja` file
- CMP0117: MSVC doesn't get the `/GR` flag from `CMAKE_CXX_FLAGS` by default
- CMP0118: any directory can now ask if a source is `GENERATED`
- CMP0119: the `LANGUAGE` source file property now selects the compiler to use
- CMP0124: `foreach` now removes loop variables at the end of the loop
- CMP0125: cache variable handling of `find_X` commands regardless of existing definitions of the variable
- CMP0126: `set(CACHE)` no longer removes local variables of the same name

If you're using these, yes, we've changed behavior on you. If not, we warn when you have a problem. If you have evidence to the contrary, please file issues.

> When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly

File bugs. We obviously can't catch everything, but if someone waits 3 years to tell us about a problem, there's obviously nothing we can do about all the releases in between. Behavior regressions are considered serious faults.

> Backwards compatibility. You keep using that word. I do not think it means what you think it means.

CMake tries extremely hard to keep compatibility with old behaviors when requested. If you file issues about concrete issues instead of just hand waving, then we can do things about it.