NOTE: I am not affiliated with Kitware, this is just my own opinion.
My experience with the cmakeExecutable presets field across different IDEs was a horrible, frustrating one. First let me say that CMakePresets.json should not normally set this field. That file would be provided by the project and checked in along with the source code. You should not typically be hard-coding a choice of CMake executable, that’s something that should be specified by the user, since only they know what is appropriate on their machine. An exception might be in corporate environments with tightly controlled developer machine configs (still not something I’d recommend though). It may be useful in a CMakeUserPresets.json file in specific cases, but because of how some IDEs treat this field, you will be constrained by what you can do with it.
My recollection after fighting with this with one of my consulting clients is that Visual Studio (not VS Code) requires whatever you put here to be an executable named cmake, and it must have a .exe extension, or else Visual Studio will forcibly append that extension. Any name other than cmake doesn’t work. This means you can’t put the name of a batch file that wraps the real cmake.exe, which was the use case I was ultimately unable to satisfy. Unfortunately, Visual Studio doesn’t give you any other way to override the location of the cmake executable when you’re using presets, other than this severely limited implementation of the cmakeExecutable field. I believe it does allow you to specify just the name of the executable and it will find it on the PATH.
VS Code and CLion are more flexible and let you specify a full path to whatever file you want in their app settings, including wrappers like shell scripts or batch files. That should mean you don’t need to specify a cmakeExecutable field in your presets, but I think VS Code will honour such a presets field if present. I think CLion would ignore that field, since it uses a separate concept of “toolchains” in its settings which are pretty central to the way their system works, but they support an “environment” file which gives you plenty of flexibility.
Not sure if that answers your question, but hopefully it helps.