Jon Sequeira

Thanks for the write-up! Could you say a bit more about how you're using these properties? Some of what you're describing here sounds related to the [completions APIs](https://docs.microsoft.com/en-us/dotnet/standard/commandline/tab-completion#get-tab-completion-values-at-run-time) . Are...

> Do I understand you correctly - global options are not copied to commands, so they are not in the list of options on the command? Correct. The old implementation...

This is a little bit indirect but I don't think you need to use reflection to get the `Option.Argument` in order to get completions for the `Argument`. The `Option` completions...

Thanks, @deg0nz! Would you be open to submitting a pull request? > However, since the fish completion system is mightier than the ones of other shells, this is not adequate...

These changes would be out of scope for the purpose of this issue (although simpler handling of piped input is something we'd like to look at after the 2.0 GA)....

You can have a bit more control over this using `ParseArgument`. There's more information here: https://docs.microsoft.com/en-us/dotnet/standard/commandline/model-binding#custom-validation-and-binding

> It appears as if the CommandLineStringSplitter.Instance.Split(commandLine) is treating arg[0] as a command, vs. arg[0] being this executable. Ah, I see what's going on. This is an intentional behavior change...

Slashes and quotes are handled by `CommandLineStringSplitter`, so you should just be able to do this: ```csharp string[] args = CommandLineStringSplitter.Instance.Split(Environment.CommandLine).ToArray()[1..]; rootCommand.Invoke(args); ```

This change was intended to make the behavior clearer. Previously, the first argument would only be stripped off if it was a possible match for the executable name, which was...

Thanks, @ptr727. This is useful context for #1758, which is a good place to continue this discussion.