A thought: if we made the setting not necessarily hot reload, we could use the --flag as discussed in #15504, #1802 to statically initialize conpty with or without support for DECKPAM

On the broader issue of passing settings from the conpty terminal down to conhost, I think it's worth considering some of the other places we may want to use it, because the different use cases may influence the way we choose to implement it.

There have been a couple of other cases similar to DECKPAM, where users have wanted to block a particular mode. One common one is cursor blinking (mode ?12), which comes up quite a lot (these are just some examples):

• No cursor after exiting vim #10754
• No blinking cursor after curses (S-Lang works fine) #10919
• cursor stops blinking on wsl2 after running top #11209
• WT stops cursor blinking after quitting Emacs nox build #12372

Another less common one is the alternate screen buffer (mode ?1049), usually in relation to the screen multiplexer:

• Invoking "screen" from Ubuntu bash shell causes scrollbar (and buffer?) to disappear. #13670
• Windows cannot scroll up or down in Screen mode #13703

Then there are the situations where conhost needs to report state that it doesn't know about, because that state is initialized (and potentially updated) by the conpty client.:

• Support querying the colors via OSC #3718
• GetConsoleScreenBufferInfoEx doesn't return the actual palette #10639
• Add support for VT100 Answerback Feature #11946
• Querying the current cursor shape with DECRQSS (I don't think this is tracked anywhere).

While the modes would probably be OK if only initialized at startup, for things like the palette and cursor shape I think it's quite important to support real-time updates, because the user will see those changes immediately, and will expect any query APIs to reflect what they're seeing.

And the other thing to consider is how this could work (if at all) when conpty is used as the basis for a telnet/ssh server. There's no opportunity there for the terminal to pass flags on the command line, or over a ioctl-like backchannel (at least as far I know).

One my initial ideas what that this could be handled by querying the connected conpty terminal on startup. That way we could use standard VT sequences, which should just work automatically with most conpty clients. But if we want real-time updates, that's not going to cut it - some mechanism for pushing updates from the terminal side would be required.

But maybe we just have to accept that the telnet/ssh situation will never be perfect.