> stdin is closed
> os.open() is called and creates a new fd=0
> a call to os.dup2(fd, 0) is made but is a noop

The dup2() silent noop case is a problem, but not the problem that's reported in msg411113. 

The two examples for this issue are fd.py and fd2.py. In fd.py, "/dev/null" is opened, and then, if the fd isn't 0, the fd is duped to inheritable fd 0. In fd2.py, fd 0 is closed, and then "/dev/null" is opened as fd 0, which isn't inheritable in Python 3.

I think the only problems regarding fd2.py are cross-platform inconsistency and/or documentation. If a similar example is tested in Windows it actually works, assuming os.devnull is used and that "sleep.exe" is available (e.g. from MSYS2). The child's stdin will be the same file as the parent's stdin.

In regard to the standard files, the subprocess documentation states the following:

     With the default settings of None, no redirection will occur; 
     the child’s file handles will be inherited from the parent.

     If close_fds is true, all file descriptors except 0, 1 and 2 
     will be closed before the child process is executed.

The above applies only to POSIX. It's not wrong in that case, but it should be emphasized that any of the standard file descriptors that's not overridden has to be inheritable in POSIX. Also, if overriding to a specific file, the file descriptor must be inheritable in POSIX. By default, file descriptors for opened files are not inheritable, so the subprocess documentation should reference os.set_inheritable(). 

For Windows it says the following:

     if close_fds is true then no handles will be inherited by
     the child process unless explicitly passed in the handle_list
     element of STARTUPINFO.lpAttributeList, or by standard handle 
     redirection.

That's mostly right, except the last part about standard handle redirection is vague. If close_fds is true, none of the standard handles of the current process is ever inherited in Windows. They could be in principle, but subprocess wasn't designed that way. When close_fds is true, and the standard handles aren't overridden, subprocess relies on the OS to duplicate (not inherit) the standard handles to the child when spawning a console application (e.g. "python.exe", but not "pythonw.exe"). If at least one is overridden, subprocess duplicates all three as inheritable handles via _make_inheritable(). (This is a choice. It doesn't have to do this. It could simply ensure that its own pipe/null files are inheritable.) Thus, when close_fds is true it never matters whether the current standard handles are inheritable, or whether a specified override is inheritable. This behavior is in stark contrast to how subprocess works in POSIX.