The main problem I see with CONPty is that it seems inextricably linked to using pipes for communications, and the Windows implementation of pipes has a number of severe limitations that make them difficult to use for ported code from Unix. I can enumerate a couple of the issues here:

First of all, pipe handles are not waitable handles. There is no easy way to do something select()-like with pipe handles - you have to resort to polling to determine if the pipe is readable, and determining writability in any real way is next to impossible.

The fact that CONPty doesn't support asynchronous I/O for pipe handles makes this problem doubly difficult - otherwise one might use named pipes with overlapped IO to help prevent at least some of the blockages.

There still exist certain pipe operations which can block indefinitely if there is a different process that is blocked in a ReadFile() on the same pipe handle. This bug has existed for ages - I have not seen any sign that this has ever been corrected. I have a testcase that I just ran on the latest Win10 (with ConPTY) and I still see the thing deadlocking until the read is satisfied. In the past I have seen such deadlocks involving CloseHandle(hPipe), GetFileInformationByHandle(hPipe, ...), and I believe a few others. There is no way to really test to see if something is going to deadlock without actually trying it.

If you clean up some of the issues related to pipes, then I might be a lot more interested in trying to use CONPty in production code.