The current way to catch any extra args at the end of the command line is to use an IEnumerable<string> property (with the Value attribute and an index higher than any other Value attributes), which will end up catching all the extra args passed on the command line. I suggest that catching extra args is such a common scenario that the extra args should always be available to the library user, whether or not they have defined a final IEnumerable<string> property in their option type. So I propose the following:

• ParserResult class, or perhaps just its Parsed subclass, gains an ExtraArgs property of type IEnumerable<string>.
• The WithParsed<T> methods in ParserResultExtensions gain another overload that takes an Action<T, IEnumerable<string>>. This will receive the parsed option instance as its first parameter, and the extra args, if any, as a second parameter. (If all args were parsed into the option instance, the extra args will be an empty IEnumerable<string>, but it is guaranteed to never be null.)
• Likewise, the WithParsed<T> methods in ParserResultExtensionsAsync will also gain an overload that takes a Func<T, IEnumerable<string>, Task>, and the second parameter is guaranteed to never be null.

Given the existence of issues like #63, it seems clear that the current design of CommandLineParser where you don't have access to any "extra" args unless you put an IEnumerable<string> into your options is not intuitive to everyone, and many people expect the library to hand them any extra args and let them decide what to do with them.

This would NOT be a breaking change, so it could go into a 2.x release, but I don't suggest holding up the 2.9 release to get this feature in.