WOW. cmd can actually parse escape codes now AND run Linux scripts! What a time to be alive.
I've been using WSL for the last year now on my Surface Pro 4, and it has been nothing short of fantastic. This bridges a HUGE gap that made the MacBook attractive.
cmd has nothing to do with it. Just as bash has nothing to do with parsing terminal escape sequences. It's a shell. On Unix-likes a terminal or ~ emulator will handle those escape sequences, on Windows it's the console (provided by conhost). What program you run in the console (or terminal) is completely irrelevant.
No, conhost.exe is (since Vista, prior to that it was a part of csrss). cmd.exe is simply the default command-line shell. To disprove your guess here, you can just observe the processes existing when running console applications. There's one conhost for each console window, but unless you run cmd, there'll be no cmd instances.
Windows didn't have a terminal emulator until recently anyway, as Windows console applications use the console APIs to change cursor position, color, etc. instead of having that API as part of the text stream that's output by applications.
Oh, fair point. I forgot about that. But it was never intended to be used with local console application ;-) (and ANSI.SYS goes back even further, I guess).
It's funny that it took so long to re-implement escape codes, while they already had support for escape codes in DOS sessions via ANSI.SYS since MS-DOS 2.0 :) https://en.wikipedia.org/wiki/ANSI.SYS
A more thoughtful critique is that it is sad that it took so long to make the console support the POSIX General Terminal Interface and terminal control codes, considering that the Windows NT Subsystem for Unix Applications (a.k.a. Interix) already had all of this working and Microsoft owned the code.
I've been using WSL for the last year now on my Surface Pro 4, and it has been nothing short of fantastic. This bridges a HUGE gap that made the MacBook attractive.