ConPTY internal API: "--flagName --flagName" or "--flags.required 0xABCD --flags.optional 0xDEF0"?

[Dustin L. Howett (DHowett)]

"In the future", we might want to add more types of conpty flags. Maybe. I don't love it, but maybe we will.

Mike and Michael used to prefer --real --arguments that set flags, rather than --flags 0xABCD to bulk enable all of 0xABCD. The argument was that it was easier spot in a debugger or a process list.

I still think there's value in having --flags 0xABCD, but this PR made me realize that maybe what we actually want is --flags.required 0x0001 --flags.optional 0x0002. Conforming versions of conhost can say, "I don't support flag 0x0001" if 0x0001 is too new for their blood... but they can ignore 0x0002 if they don't know what it is.

Is that YAGNI?

Originally posted by Dustin L. Howett (@DHowett) in #15476 (comment)

[Mike Griese (zadjii-msft)]

A thought: #15507 (comment)

a flag for "Cooked Read v2" that makes it suck less?

[Mike Griese (zadjii-msft)]

Conforming versions of conhost can say, "I don't support flag 0x0001" if 0x0001 is too new for their blood

So, this is for the case where someone is using... the system conhost, rather than one from a conpty package (that doesn't yet exist)?

IMO, if an app requires a certain flag to work, then it's kinda on them to use the package version that supports that flag. I supposed it's a little convenient to have the API just gracefully E_INVALIDARG on some flag it doesn't expect, but then we could just do that for --flags anyways.