Does this provide anything? Because if it can't yield different results than what the current logic does, it's better to save spawning a process.

The comment I referenced was the main inspiration for this PR. Given Flex has two places now where we find an executable using which/command -v instead of the executable finder, I felt it was a sign about what executable finder should be doing.

Also, I had the feeling that scanning file existence across all available paths might be heavier than spawning a short process, but I haven't had any software studies nor did I do benchmarking so that's just feelings.

In general, I always lean on using the official tools to do a job. In this case, the executable finder's job is to find an executable that can be used with the Process component. So if there is some shell doing something with a differently named PATH var, our replicated logic would break, but using the official tool wouldn't. I was under the impression that Fish' user path feature didn't use the PATH var, but after some testing I now see that user path vars are automatically part of PATH (probably because of BC reasons).

TL;DR: given we forgot to use this class in Flex and Flex used something different, I wonder about the relevance of the current executable finder. But no hard feelings if this PR is closed :)

I explained the reasoning of the current logic in the flex thread, which is based on consistency.

My opinion here is: If it ain't broken, don't fix it.