The problem was triggered by cmake/Build/BuildFLTK.cmake passing -DCMAKE_C_COMPILER=cl and -DCMAKE_CXX_COMPILER=cl to the ExternalProject call to configure FLTK. Every time FLTK re-configures, CMake converts cl to the absolute path to cl.exe, and compares it to the CMAKE_{C,CXX}_COMPILER stored in FLTK’s CMakeCache.txt. If the value has changed, CMake assumes the user is trying to reconfigure with a different compiler, and wipes out a bunch of other settings too. This shouldn’t happen in the example’s workflow, but it does with CMake 4.0.0. It triggers on a case-change to CMAKE_{C,CXX}_COMPILER because vcvarsall.bat sets PATH with .../bin/HostX64/x64 but the actual path on disk is .../bin/Hostx64/x64 (note the case of HostX64 versus Hostx64).
The comparison is platform-agnostic and case-sensitive. Both sides are supposed to be normalized to their on-disk case before the comparison. However, refactoring in CMake 4.0.0 caused that normalization to be dropped on one side. CMake MR 10620 fixes that.