In libgpg-error (also in libassuan, and gnupg 2.4.*), spawning a process with "NUL", it actually has not been working well.

w32_open_null function opens "NUL", but it is not inheritable to child process (currently, until we will fix).

Fixing this bug will introduce a regression (or two) in GnuPG, specifically, in gpg-connect-agent;
gpg-connect-agent uses gnupg_isatty to distinguish if it's user's console session or not.

On Windows, isatty returns TRUE for "NUL" (or any character devices), which is not expected.

Thus, some sort of bug compatibility support is needed.
My proposal is use of new flag GPGRT_PROCESS_STDIO_NUL means enabling "NUL".
Applications which require the behavior of having "NUL" for stdin/stdout/stderr should specify the flag GPGRT_PROCESS_STDIO_NUL. Otherwise, it's backward compatible (invalid handle in a child process).