We should be able to do better than CFEXECUTE.
1) CommandResults should include the exitValue() from the Process object. We should be able to further provide that back to the calling page. Getting the exit or return value from a process is pretty standard for anything calling external programs. Perhaps instead of having a variable, and an errorVariable, and an exitValue - we should just return a results structure, i.e. like cfhttp would. Especially since outputFile and errorFile gain nothing, because Command is just going to gobble the entire stream into memory anyway. (If it were going to instead redirect to a file, I might think differently.)

2) Provide an option to actually stream directly to a file. I don't know how big the output from a cfexecute-d process will be... in my case, usually less than 100 lines, so gobbling the stream into memory is fine. But anything returning thousands of lines or something memory significant should stream directly to disk first.

3) Providing arrays for arguments, environment, pretty much anything ProcessBuilder has supported since Java 7, without just band-aiding the parser by turning the array back into a string before execution.

4) Timeout not specified or 0 makes cfexecute useless. cfdocs.org does NOT indicate what happens when timeout<=0, but Adobe docs do - it goes into "non blocking" mode, which essentially means "Spawn a thread and return immediately"... While it's tied to the page context, no future is returned to the calling page, so you cannot check the progress of the process. I'd prefer it be blocking personally, but if it is going to do be non-blocking, we should return a future that wraps the PageContextThread and interfaces w/ the Process object so we can have truly USEFUL non-blocking.

For that matter, if something requires input or output, being able to interact with that non-blocking process would be pretty awesome. Use the future to "print" to the STDIN stream, and receive on-the-fly results from the buffered STDOUT stream, instead of assuming the process is a one-shot batch-mode no-stdin deal. (i.e. Perl https://perldoc.perl.org/IPC/Open3.html, or http://expectj.sourceforge.net/)

Since this diverges from Adobe's cfexecute semantics we're probably talking about a different, better, lucee-specific function or functions.