It seems this file is now called CMakeDetermineCompilerSupport.cmake, with a similar rename for the function it brings.
What is the adviced migration path in case this is not a bug ?
I know of cmakelists files that do :
include(CMakeDetermineCompilerFeatures)
That file is an internal implementation detail of CMake. It is not part of CMake’s public API, projects and developers should not be trying to use it directly. It can (and apparently now has in the 3.30 release) change without notice.
What would be the suggested API layer around to use for the functionality this implements ?
Let me turn the question around. What are you trying to use it for?
I asked the library author to comment and answer that question 
I assume he will report here later on.
Hey @craig.scott there is a legitimate bug here (I think?!?) which is coming out of my cross-compile build.
When CMake goes to find the CMakeTest(LANG)Compiler.cmake it uses cmMakefile::GetModulesFile which looks in the CMAKE_MODULE_PATH for the cmake file. This is fine except CMakeTest(LANG)Compiler.cmake does not use the CMAKE_MODULE_PATH it looks directly in CMAKE_ROOT calling the host version. Then when it can’t find the CMakeDetermineCompileFeatures file it croaks.
CMake’s own modules use CMAKE_ROOT rather than CMAKE_MODULE_PATH to prevent user projects from overriding CMake’s own modules. When CMake needs to include its own modules, it wants to ensure it gets its own versions, not one that a project may define. See policy CMP0017 which made this default behavior and which is now enforced to always be using the NEW behavior. The include() command docs also mention this behavior.
I also don’t see how this relates to the original discussion topic. If this is a different problem, please create a new topic to continue discussion.