This would indeed be useful. I have written a JavaExecAsync task and supporting classes which make it possible to javaexec into a separate thread. It turns out the classes for the existing JavaExec task are actually designed to support this so this is a small change.
When using the gradle daemon the user experience is more or less what you require: the gradle command line execution returns, but the thing it started lives on…in the gradle daemon process.
However, if you end up needing to kill the gradle daemon for whatever reason, your thread and everything with it will go down in flames. Also if you end up needing to kill the thing you started, the only way of doing this is killing the gradle daemon. If you started more than one thread, there is no way of killing just one of them.
I’m also not really a fan of leaving threads around in the daemon as they might have side effects on subsequent builds. An example a side effect we have seen is when threads spawned in previous builds do error logging into the console of a subsequent build…not great when the currently executing build is sitting on a CI server and triggering a build failure on error log messages. Even without CI this behavior can be quite unintuitive.