Yes, that'd be the call in question; it requires cross-platform vt100 apps to specifically know about and call a feature on windows in order to enable it. They can't just emit control characters to terminal, they must call this WinRT function first. This isn't something you can fix, for the reasons you listed, but it's something that's true.
As a side note, Windows Terminal (the app) is absolutely fine letting programs emit and handle VT100 escapes without them issuing any particular opt-in call themselves... And upon looking, you're the person who enabled this feature! Thanks for that, but, why is it good for terminal but bad for conhost?
Sorry, I had my Microsoft-colored glasses on. We use WinRT almost exclusively to refer to the new COM-based API surface that “modern” applications use. I see now that I’ve misunderstood you :)
Back when VT parsing was implemented, it was an entirely new output stream parser built into a console that hadn’t been updated in a rather long time. We were careful commensurate with its age, and opt-in made sense. Language runtimes or compatibility layers like Cygwin could handle the decision for all of their hosted applications(1) and everything else would generally continue working properly. Now that we’re working on conhost’s replacement, we get to revisit some of those decisions!
Cases like this are especially acceptable because a user can always fall back to conhost. That escape hatch isn’t one we intend to get rid of.
1) this doesn’t do anything for manual or direct ports, and Cygwin is far from the only provider here. Representative example, etc.
As a side note, Windows Terminal (the app) is absolutely fine letting programs emit and handle VT100 escapes without them issuing any particular opt-in call themselves... And upon looking, you're the person who enabled this feature! Thanks for that, but, why is it good for terminal but bad for conhost?