There should be a possibility to change the environment of a process created with multiprocessing.

For subprocess this is possible thanks to the "env" attribute.

Elaboration:
While it is trivial to change os.environ manually, in some cases this is not possible. 

For instance: creating a COM process on Windows; this process will always inherit the environment of the host process.
A workaround is to spawn a python process with a different environment which then will provide this to the child COM process.

Why is not having the target assign to the relevant os.environ keys before doing whatever depends on the environment not an option?

Because sometimes when a process is implicitly started by some 3rd party library (i.e. COM via pythonwin here) the "old", unchanged environment is retained as the process itself doesn't care if os.environ was changed or not, the original environment cannot be modified.

This solution would give a lot of flexibility in that regard.

I think pythonwin is actually a special case as the problem here lies somewhere in the dispatch(.) call. The process creation should be handled somewhere within the COM interface, pywin does nothing there. 

But this solution effectively circumvents that issue.

> Because sometimes when a process is implicitly started by some 3rd 
> party library (i.e. COM via pythonwin here) the "old", unchanged 
> environment is retained as the process itself doesn't care if 
> os.environ was changed or not, the original environment cannot 
> be modified.

What "old" environment are we talking about? The os.environ mapping is implemented to immediately modify the process environment block. For example:

Python:

    >>> os.environ['SPAM'] = 'EGGS'

Debugger:

    Breakpoint 0 hit
    KERNELBASE!SetEnvironmentVariableW:
    00007fff`8ae3ee30 4053            push    rbx
    0:000> kc 6
    Call Site
    KERNELBASE!SetEnvironmentVariableW
    ucrtbase!common_set_variable_in_environment_nolock<wchar_t>
    ucrtbase!common_putenv_nolock<wchar_t>
    ucrtbase!common_putenv<wchar_t>
    python37!os_putenv_impl
    python37!os_putenv

    0:000> du @rcx
    00000215`70dd57c0  "SPAM"
    0:000> du @rdx
    00000215`70dd57ca  "EGGS"

Alright, thanks for pointing me in the right direction.

I have to conclude that this issue is not present on a current operating system, as I now tried to reproduce with Windows 10 (I came across it on an ancient Windows XP (sic) system - I can just imagine putenv didn't do its job as requested).

I suppose this can be closed then!

Among other things, the version of the C runtime you were using on that old system probably has its own set of bugs that have since been resolved.

Thanks for reporting the issue, though!