npth_t is untouched for Windows 64-bit.

npth_connect and npth_accept should deprecated (since it's not consistent with 64-bit Windows). In gnupg master, there is no use.

In libassuan 3.0, we distinguish the integer identifier for process and the HANDLE (by T6487).
This was problem was solved.

Merged to master (to be 3.0.0).

Since it's ABI change, I created a branch: https://dev.gnupg.org/source/libassuan/history/gniibe%252Ft6487/

I conclude that adding two public functions for pipe connection of client will be useful (and solve the pid_t issue, by successfully hiding those use cases).

For (2-2), there are two use cases in GnuPG.
(A) In call-daemon.c (for SCD and TPM2D), wait_child_thread cares about daemon termination to clean up resources. In this case, it calls waitpid/WaitForSingleObject.
(B) In call-pinentry.c, watch_sock cares about dangling pinentry. When it detects client's EOF on the socket (between the client and gpg-agent), it kills pinentry process. In this case, it calls kill/TerminateProcess.

Finished the step to have cleaner semantics of the implementation by: rA6350f796fdd1: w32: Cleaner semantics for PID and Process handle.
Clarified the fact (1-1).
And as a bonus, when it's "cygwin" mode, peer (client) process ID is now available.

AFAIK, Microsoft stated that the value of a HANDLE will always fit into a DWORD; i.e. only the lower 32 bits are used even on a 64 bit Windows.

Now, we implemented fd passing on Windows in libassuan.
Note that the process identifier (represented by DWORD) and handle for a process (represented by HANDLE) are different things.

SOCKET handle is UINT_PTR on Windows. It is u_int on original MinGW, it is UINT_PTR (and unsinged __int64_t) on MinGW-W64.

Original MinGW and MinGW-w64 handle differently.
For MinGW-w64 on 64-bit machine, pid_t is 64-bit integer.
For original MinGW on 64-bit machine, pid_t is 32-bit integer.