anchor.diff:  
   === Overwriting Single Options
   
  -When a single-value option is specified multiple times on the command line, the default parser behaviour is
  -to throw an `OverwrittenOptionException`. For example:
  +When a single-value option is specified multiple times on the command line, the default parser behaviour is to throw an `OverwrittenOptionException`.
  +For example:
   [source,java]
   ----
   @Option(name = "-p") int port;
  
positive.code: When the unmatched value is similar to the known options, picocli throws an `UnmatchedArgumentException`
  rather than treating it as a positional parameter.
  
  As usual, `CommandLine.setUnmatchedArgumentsAllowed(true)` will accept unmatched input and
  display a WARN-level message on the console.
  
  
  Arguments that are not considered similar to the known options are interpreted as positional parameters:
  
negative.code: Prior to 4.0, the default was to "toggle" boolean flags to the opposite of their _current_ value:
  if the previous value was `true` it is set to `false`, and when the value was `false` it is set to `true`.
  
  Applications can call `CommandLine::setToggleBooleanFlags` with `true` to enable toggling.
  Note that when toggling is enabled, specifying a flag option twice on the command line will have no effect because they cancel each other out.
  
  
  === POSIX Clustered Short Options
  By default, the picocli parser allows POSIX clustered short options, so short options like `-x -v -f SomeFile` can be clustered together like `-xvfSomeFile`.
  From picocli 3.0, applications can call `CommandLine::setPosixClusteredShortOptionsAllowed` with `false` to enforce that options must be separated with whitespace on the command line.
  (This also means that option parameters must be separated from the option name by whitespace or the `=` <<Option-Parameter Separators,separator>> character, so `-D key=value` and `-D=key=value` will be recognized but `-Dkey=value` will not.)
  
  === Lenient Mode
  From picocli 3.2, the parser can be configured to continue parsing invalid input to the end.
  When `collectErrors` is set to `true`, and a problem occurs during parsing, an `Exception` is added to the list returned by `ParseResult::errors` and parsing continues. The default behaviour (when `collectErrors` is `false`) is to abort parsing by throwing the `Exception`.
  
  This is useful when generating completion candidates on partial input, and is also useful when using picocli in
  languages like Clojure where idiomatic error handling does not involve throwing and catching exceptions.
  