Why can't an implicit close be permitted when the Subprocess deinits?
Having an explicit terminate() function (or similar) is fine too, for cases where that's more convenient than letting the instance fall out of scope.
It's true that users might stash a Subprocess somewhere persistent unnecessarily, but that's true of anything. I don't think Subprocess needs to be particularly defensive about that. Most uses (for the API style I'm advocating) would be contained to a single function and so deinit-on-scope-termination is perfectly fine.
Yes; why not?
(I've never much liked thread / task / similar APIs that make you explicitly call some parameterless start() method - it seems pointless and forces the object to be stateful)
You mean if the Subprocess deinits because it naturally goes out of scope? Why wouldn't you just kill it then? The caller has indicated that they don't need it anymore.
If they do want it to live, they can await its exit. If they still care about it (e.g. it's a background upload via curl), they need to check its exit status anyway.
When the Subprocess goes away, or the caller explicitly indicates they should be closed (a common requirement for stdin to the subprocess, as many programs need to see EOF on stdin to conclude). Seems no different to the closure case, really?