> Python can safely removes the string to _putenv() just after the call? 

Windows ucrt copies the buffer that's passed to _[w]putenv. This makes it non-compliant with POSIX but easier to use in this case. Here's an example using ctypes:

    >>> ucrt = ctypes.CDLL('ucrtbase')
    >>> buf = ctypes.create_unicode_buffer('spam=eggs')
    >>> ucrt._wputenv(buf)
    0

Directly modifying the buffer has no effect on the _wgetenv result:

    >>> buf[5] = 'a'
    >>> ucrt._wgetenv.restype = ctypes.POINTER(ctypes.c_wchar)
    >>> ucrt._wgetenv('spam')[:4]
    'eggs'

Linux putenv complies with POSIX, so changing "eggs" to "aggs" in the buffer does affect the getenv result in Linux. 

On the other hand, ucrt's [_w]getenv does not copy the environment string. For example:

    >>> p1 = ucrt._wgetenv('spam')
    >>> p1[0] = 'o'

    >>> p2 = ucrt._wgetenv('spam')
    >>> p2[:4]
    'oggs'

[_w]getenv is not thread safe. Even though all calls that access the ucrt environment are internally synchronized on a common lock, accessing the *result* from [_w]getenv still needs to be synchronized with concurrent _[w]putenv calls in a multithreaded process. Better still, use [_w]getenv_s or _[w]dupenv_s, which returns a copy.

> There is also _wputenv_s which affects _spawn, _exec and system.

The documentation is perhaps misleading. When a variable is set with _[w]putenv[_s], it also sets the variable in the process environment block to stay in sync. This indirectly affects _spawn*, _exec* and system(). common_spawnv (in ucrt\exec\spawnv.cpp), which implements the latter functions, calls CreateProcess with lpEnvironment as NULL (i.e.  inherit the current process environment), unless the caller passes a new environment (e.g. envp of spawnve).