Ok, here's a patch for the new approach.
CancelIoEx is loaded dynamically and, if unavailable, CancelIo is used instead. I take care to cancel or complete the I/O in the same method call where it is initiated, meaning there's no thread-specificity issues.

(of course, all this is a lot of code just to have the desired WaitForMultipleObjects() semantics on a named pipe. Thank you, Windows)