Currently the handing of filesystem paths is not quite optimal:
- Handling is dispatched on two commands:
get_filename_componentandfile -
get_filename_componentis a bit counterintuitive because it is used for operations other than extracting component from filename - Some basic capabilities are not available (see #19568)
Moreover, it is not clear which operations require filesystem access or not. And even more curious, get_filename_component can be used to read the Windows registry (not documented).
So, I propose to introduce the new command cmake_path to manage all operations on path not requiring filesystem access (same semantic as std::filesystem::path C++ class) and use file command for operations requiring filesystem access (so get_filename_component(REALPATH) should be offered as part of file).
For the command name, path should be nice, but I am afraid that it is no longer possible to introduce a such name without creating conflicts with existing user’s code. And, anyway, the goal is not handle paths in CMake format…
For the possible operations of cmake_path, I propose to follow what is offered by std::filesystem::path with a CMake twist of course 
And for Windows registry access, may be a dedicated command should be fine. Or a module relying on reg windows command should be fine as well.
@brad.king, @craig.scott, @kyle.edwards Comments welcome.