> icacls.exe C:\Python38-32\python.exe lists Mandatory Label\
> Low Mandatory Level:(I)(NW) ** This might be the problem. Removing "L"
> with icacls might work.
>
> **When a user attempts to launch an executable file, the new process is
> created with the minimum of the user integrity level and the file 
> integrity level.**

The token mandatory policy [1] for a standard logon is TOKEN_MANDATORY_POLICY_NO_WRITE_UP (1) and TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN (2). The above quote applies to the latter. For an elevated logon, the mandatory policy is just TOKEN_MANDATORY_POLICY_NO_WRITE_UP, so setting a low-integrity label on python.exe has no effect on a new process created from an elevated security context. The following queries demonstrate the mandatory policy for both cases:

standard logon:

    >>> GetTokenInformation(-4, TokenMandatoryPolicy)
    3

elevated logon:

    >>> GetTokenInformation(-4, TokenMandatoryPolicy)
    1

> >icacls.exe C:\
> C:\ BUILTIN\Administrators:(F)
>     BUILTIN\Administrators:(OI)(CI)(IO)(F)
>     NT AUTHORITY\SYSTEM:(F)
>     NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
>     BUILTIN\User:(OI)(CI)(RX)
>     NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
>     NT AUTHORITY\Authenticated Users:(AD)
>     Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

Something has modified the security on the root directory of your system drive. The low-integrity no-write-up (NW) label that's inheritable by directories (CI) and files (OI) is the source of the problem. It's supposed to be a high-integrity no-write-up (NW) label that applies to files in the root directory (OI)(NP) and not to the root directory itself (IO) or subdirectories (no CI):

    Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)

> I used to UNIX-syntax as a short-hand for specified permissions relating
> to a specified user. I can see how that could introduce misunderstandings
> for everyone glancing over the text.

I was concerned that you were using a third-party tools such as MSYS2 bash to check permissions. POSIX rwx access for a user can be computed in terms of effective permissions and generic read, write, and execute access rights. But there's no equivalent to POSIX owner and group permissions. Access for a user SID has to be computed against all entries in the DACL and the mandatory label.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-token_mandatory_policy