Jon Sequeira

I updated your comment a little for readability. The help output does look a bit off. This is being partially addressed by #1335, I think.

Given this parser: ```csharp var command = new RootCommand { new Option("-s", "An option"), new Argument("arg", "An argument"), new Command("subcommand", "A subcommand") }; ``` The following is the current help...

Thanks, @andrewimcclement. The bug was fixed elsewhere. Sealing `Token` is a reasonable thing to do. If you'd like to resubmit that change, I'd be happy to merge it.

I wonder if another helper method like this work: https://github.com/dotnet/command-line-api/blob/74ae46ea8571269a66945049ce9f134a91d67d1e/src/System.CommandLine/Help/HelpBuilderExtensions.cs#L31-L40 `HelpBuilder.Write` also takes a `HelpContext` and keeping things consistent on this type leaves an opening to add things to the...

I wonder if that suggests that the problem isn't so much the `HelpContext` as the fact that it's so `Command`-centric.

One approach off the top of my head could be to change `HelpBuilder.Write` to accept `Symbol` and change `HelpContext.Command` to `HelpContext.Symbol`. That might have a bit of a ripple effect,...

This is intentional. The `@` character indicates a response file. https://github.com/dotnet/command-line-api/blob/main/docs/Features-overview.md#response-files

There's an interesting question here about how the user rather than the tool developer should specify an argument beginning with "@" when response files are enabled. There should be a...

I've been unable to find prior art for escaping a token on the command line that could indicate a response file. Suggestions are welcome. I'll put forward an approach we...

These are all good suggestions, though I worry that interpreting the `@` prefix contextually would be difficult to reason about. Right now we inline the replacement tokens very mechanically, and...