That is _technically_ correct (the best kind). There's some plumbing between conhost and Terminal we need to clean up before we can add it to Terminal too. We've got a branch ready, we've just got to merge a whole stack of PRs first before we can get there.
Conhost and Terminal share quite a lot of code in fact. The text buffer, the renderer, the VT sequence parser - all that's the same codebase. That allows bugfixes and improvements to the the Terminal to also flow back to the vintage console (for people who still use that)
We shipped it (the Terminal) with the first versions of Windows 11. I don't think the "default terminal" feature defaulted to the new Terminal in the first win11 builds, but it should now. And you can always pick whichever terminal you want as the default terminal
There are some fun things you can do with it like terminal image viewing, etc. The notcurses library uses it, some of their demo videos are really neat.
I think it was necroed by a Japanese Twitter addict(@tsutsuii) to display Twitter user icons without X on NetBSD/luna68k, then others started doing all sorts of unholy things with it from w3m with images to terminal-based RDP client.
There aren't a lot of "legitimate" use cases for now, I believe, but it's neat, and IMO an image mode extension for tty kind of makes it whole.
which supported a set of commands similar to the drawing commands in BASIC back in the day but supported more and better colors than home computers at the time and could also freely mix graphics and text. Since the PDP-11 supported BASIC you could write graphical programs in BASIC that would draw on the terminal using the right character sequences.
kitty is a product of a single open-source project, Sixel is a product of DEC with multiple independent implementations. DEC is out of business and there's very little risk of anyone coming out with a new version of VT333/VT340 reference manual, so Windows Terminal/conhost can have its own implementation of Sixel and ensure interoperability with other implementations as it sees fit, as opposed to committing to either chase compatibility with the Kitty project or committing to shipping someone else's code in perpetuity.
Kitty's standard is described for other people to implement both emulators and clients for. Since this relationship already exists, there's enough friction between emulators implementing new features, and clients actually using them (in a backwards-incompatible way), that I believe one can be relatively sure their emulator will support clients well into the future.
Either way, I agree that kitty's protocol should become a versioned standard, but I also don't think that people will be very quick to change it at this point.
I kind of lament that a format that was invented for dot matrix printers, where switching heads is a costly operation, transfer speeds don't matter since moving the head is a bottleneck, and color accuracy doesn't matter as the technology wasn't there yet, is being revived, as opposed to some of the more modern ideas for doing this... It doesn't make sense in a terminal emulator context at all.
