Yes, I have a workaround (and even a clean solution) in my code.  My interest in this ticket is more academic than anything else :)

Thanks for the pointer to issue1731717.  While I am not sure which 'comment at the end' you exactly refer to, the whole discussion provides some more insight on why SIGCHLD is handled the way it is, so that was interesting.  

I agree that changing the behavior in a way which is unexpected for existing applications is something one wants to avoid, generally.  I can't judge if it is worth to break existing code to get more correctness in a corner case -- depends on how much (and what kind of) code relies on it, which I have no idea about.

One option to minimize change and improve correctness might be to keep track of the parent process.  So one would keep self.parent=os.getpid() along with self.pid.  In the implementation of _internal_poll one can then check if self.parent==os.getpid() still holds, and raise an ECHILD or EINVAL otherwise.  That would catch the pickle/unpickle across processes case (I don't know Python well enough to see if there are easier ways to check if a class instance is passed across process boundaries).

The above would still not be fully POSIX (it ignores process groups which would allow to wait on non-direct descendants), but going down that route would probably almost result in a reimplementation of what libc does...