Mono.Options comes as a Nuget package that adds source code to our solution. As the doc says is based on callbacks, that is a delegate that gets executed as soon as the command line argument is parsed.
Everything revolves around the
OptionSet and a "mini DSL” that defines the arguments and their aliases, a piece of documentation and the delegate to be executed when the options is present.
OptionSet helps with the parsing of the arguments and displaying the documentation.
Although the mandatory character of an argument can be expressed in the mini-DSL (the semi-colon for location) I was not able to get any sort of validation
A generic overload can be used to transform arguments to a given type. It is pretty basic, I was not able to convert to int?. It does a good enough job to show when conversion fails.
A given argument can be included multiple times and, since the delegate executes multiple times, add to a temporary list each one of the values.
Mono.Options does not support the concept of different commands. I prefer not to discuss whether this is a good or a bad thing (focused tools vs. discoverability in single-entry-point)
Each command sets an action with its own execution. I find it sub-optimal, but works. But it has some downsides: there is no way to tell the user which arguments are commands and which are not; both arguments can be included, and the last one will be the winner; and worse, it is not possible to express which arguments corresponds to which command.
If multiple command dispatching is a big deal for you, then I would say that Mono.Options by itself is not for you. Other frameworks augment Mono.Options, which is a sign that it does several things right and it is simple enough to recommend it over you own code for simple applications that contain one single command and do not need fancy parameter binding.