The documentation for multiprocessing.exitcode says:
"""
The child’s exit code. This will be None if the process has not yet terminated. A negative value -N indicates that the child was terminated by signal N.
"""

This is true for the "fork" method, but not "forkserver" where a child terminated by a signal will get an exitcode of 255. This is because forkserver relies on the child writing its own exit code in a pipe, which obviously doesn't work if it was killed (255 is simply a fallback value).

See forkserver's Popen.poll():

    def poll(self, flag=os.WNOHANG):
        if self.returncode is None:
            from multiprocessing.connection import wait
            timeout = 0 if flag == os.WNOHANG else None
            if not wait([self.sentinel], timeout):
                return None
            try:
                self.returncode = forkserver.read_unsigned(self.sentinel)
            except (OSError, EOFError):
                # The process ended abnormally perhaps because of a signal
                self.returncode = 255
        return self.returncode

New changeset dfd5f34 by Antoine Pitrou in branch 'master':
Fix bpo-30589: improve Process.exitcode with forkserver (bpo-1989)
dfd5f34

I've merged a fix for Python 3.7. Since the fix is a bit delicate, I don't want to risk regression by merging it into 3.6 and 3.5. Closing now.

In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.

It helper uncover a serious reliability issues in CPython's delivery of signals (https://bugs.python.org/issue30703) and then triggered the discovery of a more minor bug in our setitimer() wrapper (https://bugs.python.org/issue30807).

Hopefully signal processing is more reliable in Python now!