Should option tokens be greedy with regard to subsequent bundled option or subcommand tokens?

[jonsequitur]

Currently, the token following a known option token is not treated as an argument. This means that if the subsequent token matches a subcommand, it will be treated as a subcommand

var optionA = new Option<string>("-a") { Arity = ArgumentArity.ZeroOrOne };
var optionB = new Option<bool>("-b");
var optionC = new Option<bool>("-c");

var command = new RootCommand
{
    optionA,
    optionB,
    optionC
};

var result = command.Parse("-a -bc"); // -> [ root [ -a ] [ -b <True> ] [ -c <True> ] ]

var optionA = new Option<string>("-a");
var root = new RootCommand
{
    new Command("subcommand"),
    optionA
};

var result = root.Parse("-a subcommand"); // -> [ root [ -a ] [ subcommand ] ]

Should this behavior be changed so that the subsequent token would be considered an argument to the option, producing the following results, respectively, for the above examples?

[ root [ -a <-bc> ]
[ root [ -a <subcommand> ]

[elgonzo]

In my opion the "greedy" behavior should be default.

Otherwise, this has to be documented, including in the help text as generated by System.CommandLine. Imagine having to document/explain that the argument following an option has to be different from any other option/subcommand name, otherwise you, the user, has to invoke the commandline of the program in this or that other way. This not only can become akward and confusing. but it also makes the user responsible for checking whether the argument value they provided matches by chance a subcommand or another option. It might perhaps even make otherwise valid commandline invocations impossible.

What if the user actually wants to assign the value "-b" to the option -a? What if the CLI in question should allow program invocation without invoking a subcommand (in other words, the root command has a handler) and the user wants to provide -a with a "subcommand" value? How could they do this if options are non-greedy?

The greedy approach avoids all this. Documentation and help text remain relatively simple and there are no special cases involved where an argument value by chance collides with other option or subcommand names.

For those who prefer the "special case"-ness of the non-greedy behavior, perhaps there could be a setting offered by System.CommandLine to enable non-greedy behavior if desired. (Perhaps as an extension method applicable to RootCommand instances which effects this setting on the root command, all its descendent sub commands and options.)