For some options, errors in the parse result results in their associated actions instead of ParseErrorAction

[barrygiles]

I expect this is by design but was a surprise to me and I don't fully understand the motivations behind it.

Passing an additional parameter to a sub command results in an error in the parse result and a ParseErrorAction, which when invoked, prints out the error.

Passing an additional parameter to --version or --help also results in an error in the parse result, but the action is HelpAction or VersionOptionAction, which either prints help or the version without any mention of the parse error.

This seems inconsistent to me, but I'm guessing there might be conventions around this I'm not aware of.
I could probably intercept the parse result in these circumstances and invoke a manually created ParseErrorAction or something similar, but this might be a bit messy and might be unnecessary if there are good reasons to stick with this behaviour.

Using System.CommandLine 2.0.0-beta4.24324.3.

[KalleOlaviNiemitalo]

Seems consistent with GNU diffutils at least:

$ diff a b c d
diff: extra operand 'c'
diff: Try 'diff --help' for more information.

$ diff a b c d --help
Usage: diff [OPTION]... FILES
Compare FILES line by line.
[…]