> * To avoid repeating long parameter lists in several functions, we can move them to a struct. The downside is that we'd need to convert child_exec() to use that struct all over the place. I don't have a strong preference here.

Agreed that the long parameter lists are annoying.  I don't like shoving that much on the stack and by adding an additional call with so many params we've increase stack usage.  I consider this refactoring work that can be done on its own outside of this issue though.

> * Are any documentation changes needed? We don't change any interfaces, so I'm not sure.

I don't think so.  I looked things over and I think all that is needed is the existing Misc/NEWS entry.

> Potential future directions:
> 
> * If desired, a vfork() opt-out may be implemented. But it'd need to disable posix_spawn() on Linux as well, since it might be implemented via vfork(), and we have no good way to check that.

We have such an opt-out capabilty for posix_spawn via `subprocess._USE_POSIX_SPAWN` https://github.com/python/cpython/blob/master/Lib/subprocess.py#L651
along with code in there that determines the default value based on the detected runtime environment.

I'm not sure we'll need that for vfork() as it seems to pretty much be a low level raw system call wrapper rather than something to be implemented via libc that can have its own bugs.  If we do wind up wanting one, I'd structure it the same way.