Background Discussion

The Windows 10 console uses the condrv.sys device driver, which is set up as follows in the NT namespace:

    C:\>odir \ -r -n con;con*$;cond*
    Directory of \

    Device
        ConDrv <Device>
    Driver
        condrv <Driver>
    GLOBAL??
        CON -> \Device\ConDrv\Console
        CONIN$ -> \Device\ConDrv\CurrentIn
        CONOUT$ -> \Device\ConDrv\CurrentOut

Previously the base console API used an NT LPC port to communicate with the attached console process (i.e. an instance of conhost.exe). There wasn't a real console device. Instead, opening "CON", "CONIN$", or "CONOUT$" was special cased to call OpenConsoleW (undocumented). 

With the new console device driver, opening the DOS "CON" device gets translated to the NT path "\Device\ConDrv\Console", i.e. it opens the file named "Console" on the ConDrv device. 

Opening the Console file returns a handle for a regular kernel File object. To that end, you may have noticed that console handles in Windows 10 are no longer tagged for routing by setting the lower two bits (e.g. 3, 7, 11, etc). For example:

    >>> kernel32.GetStdHandle(STD_INPUT_HANDLE)
    32
    >>> kernel32.DebugBreak()
    (e1c.e20): Break instruction exception - code 80000003 (first chance)
    KERNELBASE!DebugBreak+0x2:
    00007ffa`60280262 cc              int     3

    0:000> !handle 32
    Handle 32
      Type          File

Previously, all operations on console handles were internally routed to special console functions, such as ReadFile => ReadConsoleA. Thus with the old LPC-based console, a ReadFile basically has the behavior of ReadConsoleA (with the addition of special casing input lines that start with Ctrl+Z). 

The new design scraps a lot of the special-cased code. For example, reading from a console handle in Windows 10 uses a regular NtReadFile system call. So the error it sets, if any at all, depends on translating the NTSTATUS code that's returned by NtReadFile. Let's see what status the console sets here:

    C:\Temp>cdb -xi ld python ccbug.py

    [...]

    ntdll!LdrpDoDebuggerBreak+0x30:
    00007ffb`170de260 cc              int     3
    0:000> g
    3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25)
    [MSC v.1900 64 bit (AMD64)]

    calling DebugBreak...
    (8d0.62c): Break instruction exception - code 80000003 (first chance)
    KERNELBASE!DebugBreak+0x2:
    00007ffb`13f40262 cc              int     3
    0:000> bp ntdll!NtReadFile
    0:000> g
    Breakpoint 0 hit
    ntdll!NtReadFile:
    00007ffb`170b35d0 4c8bd1          mov     r10,rcx
    0:000> pt
    ntdll!NtReadFile+0xa:
    00007ffb`170b35da c3              ret
    0:000> r rax
    rax=0000000000000101

The console weirdly returns a success code, STATUS_ALERTED (0x101, "the delay completed because the thread was alerted"), which is why ReadFile doesn't set an error. STATUS_ALERTED is normally returned when an NT wait function gets alerted by NtAlertThread (note that this is not the same as getting alerted by an asynchronous procedure call). For example:
    
    tid = threading.get_ident()
    h = kernel32.OpenThread(MAXIMUM_ALLOWED, 0, tid)
    t = threading.Timer(5, ntdll.NtAlertThread, (h,))
    delay = LARGE_INTEGER(10 * -10**7) # 10 seconds
    t.start()
    r = ntdll.NtDelayExecution(True, byref(delay))

    >>> hex(r)
    '0x101'

NtAlertThread is rarely used because WinAPI wait functions (e.g. SleepEx) automatically restart a wait when the underlying NT wait returns STATUS_ALERTED. 

The ReadConsole implementation has always translated STATUS_ALERTED to ERROR_OPERATION_ABORTED. This still exists in the Windows 10 implementation of ReadConsole. However, the correct error status for this case is STATUS_CANCELLED (0xC0000120, "the I/O request was cancelled"): 

    >>> ntdll.RtlNtStatusToDosError(0xC0000120)
    995

Whoever reimplemented the console IPC using a device driver should have updated the console to return STATUS_CANCELLED when an I/O operation is interrupted by Ctrl+C or Ctrl+Break. Then nothing would need to be special cased.