On second thought, I think the fact that the console leaves the previously entered text on the line is ugly and confusing. The text isn't in the input buffer, so it won't be read. Yet there's no way for the user to even clear it -- not by escape or backspace. I think the user is better served if we settle for less. 

We can try to write a CRLF to the input buffer via WriteConsoleInputW and then continue. The next read will return immediately, and we'll drop out of the loop, retaining however much was read prior to the canceled read. The console's cooked read will take care of advancing the cursor to the next line for us. If WriteConsoleInputW fails (e.g. the file is "CON", opened with only generic-read access), we can fall back on directly writing "\r\n" to the buffer instead of continuing. However this won't advance the cursor to the next line.

I think we should also merge in the CancelSynchronousIo abort case, i.e. where n_read is still the initial value of (DWORD)-1.