All these in multiprocessing.h are lacking suitable py/_py/Py/_Py/PY/_PY
prefixes:

PyObject *mp_SetError(PyObject *Type, int num);
extern PyObject *pickle_dumps;
extern PyObject *pickle_loads;
extern PyObject *pickle_protocol;
extern PyObject *BufferTooShort;
extern PyTypeObject SemLockType;
extern PyTypeObject ConnectionType;
extern PyTypeObject PipeConnectionType;
extern HANDLE sigint_event;

Additionally, win32_functions.c exposes Win32Type and
create_win32_namespace.

semaphore.c has sem_timedwait_save.

multiprocessing.c has ProcessError.

Is this really that much of an issue? multiprocessing lives in it's own
directory and isn't part of the Python public API.

The directory is irrelevant.  C typically uses a flat namespace for
symbols.  If python loads this library it will conflict with any other
libraries using the same name.  This has happened numerous times in the
past, so there's no questioning the correct practises.

Alternatively, I think the _multiprocessing module should be rewritten
to use a single C file only, and make all symbols except its init
function static.

I agree with Adam that the current code needs to be fixed, one way or
the other.

Python 3.4 no longer exports symbols without a Py or _Py prefix:

$ nm -p build/lib.linux-x86_64-3.4-pydebug/_multiprocessing.cpython-34dm.so | sed -n "/ [TDB] /s/.* //p" | sort
__bss_start
_edata
_end
_fini
_init
PyInit__multiprocessing
_PyMp_SemLockType
_PyMp_SetError

Python 3.3 still does but I don't like to modify the ABI in a patch release.

$ nm -p build/lib.linux-x86_64-3.3-pydebug/_multiprocessing.cpython-33dm.so | sed -n "/ [TDB] /s/.* //p" | sort
__bss_start
BufferTooShort
_edata
_end
_fini
_init
mp_SetError
ProcessError
PyInit__multiprocessing
SemLockType