And it's existence is significant. Ordinary users cannot write to "HKLM\...\App Paths", but they can write to "HKCU\...\App Paths". TCC already looks in "HKLM\...\App Paths" when resolving EXE names. I suspect the next version will also look in "HKCU\...\App Paths", giving the user the advantage of being able to find more EXEs which are not in %PATH.
Explorer also searches "App Paths". That's why I can enter "excel", "winword", "outlook", "textpad" (and others) in the Start\Run dialog when none of them are in my path. I'd call TCC's doing it a feature.
TCC typically uses CreateProcess() to start apps ... not shell functions. So if it's going to look in "App Paths" it must do it manually.
Does your example (3 posts ago) use CMD? Here, textpad.exe is only mentioned in "App Paths" and TCC finds it while CMD doesn't.
v:\> ver & which textpad
TCC 23.00.31 x64 Windows 10 [Version 10.0.17763.55]
textpad is an external : C:\apps\textpad\textpad.exe
v:\> cmd /c ver ^& textpad.exe
Microsoft Windows [Version 10.0.17763.55]
'textpad.exe' is not recognized as an internal or external command,
operable program or batch file.
No, it doesn't. Far manager uses internal app starter, unless you Shift+Enter.
In which case it uses ShellExecuteEx().
Internal starter does not use ShellExecuteEx() directly, but is compatible with it.