From the linked issue:

> proc.send_signal(CTRL_C_EVENT) raises the KeyboardInterrupt
> in both the original and subprocess on Windows

GenerateConsoleCtrlEvent takes process group IDs, so it should have been used to implement os.killpg, not os.kill. If you call it on a process ID that's attached to the console that isn't also a group ID (i.e. the group leader), then it defaults to group 0, which includes every process that's attached to the console. 

Popen.send_signal should only send CTRL_C_EVENT or CTRL_BREAK_EVENT when the child process was created with CREATE_NEW_PROCESS_GROUP in its creationflags. Also, since kill() falls back on TerminateProcess, for added safety send_signal also needs to call poll() instead of using returncode because Windows reuses process IDs. Also, to avoid confusion, it should be noted that CTRL_C_EVENT will be ignored by a process in a new group unless said process manually enables Ctrl+C handling by calling SetConsoleCtrlHandler(NULL, FALSE). This setting will be inherited by child processes.

In the long run I think it would be better to clarify this by implementing os.killpg on Windows using GenerateConsoleCtrlEvent, with support for CTRL_C_EVENT, CTRL_BREAK_EVENT, SIGINT, and SIGBREAK. Deprecate using os.kill to send console control events. There is no Windows API to send a console control event to a particular process ID.