anchor.diff:  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.
  +As usual, calling `CommandLine::setUnmatchedArgumentsAllowed` with `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:
  
positive.code: }
  AbbreviationsAndPosix app = new AbbreviationsAndPosix();
  new CommandLine(app).setAbbreviatedOptionsAllowed(true).parseArgs("-AB");
  assertTrue(app.aaaBbb);
  assertFalse(app.a);
  assertFalse(app.b);
  ----
  
negative.code: .Examples of valid abbreviations
  [options="header"]
  |===
  |Option or Subcommand|Sample Recognized Abbreviations
  |`--veryLongCamelCase` | `--very`, `--vLCC`, `--vCase` (...)
  |`--super-long-option` | `--sup`, `--sLO`, `--s-l-o`, `--s-lon`, `--s-opt`, `--sOpt` (...)
  |`some-long-command` | `so`, `sLC`, `s-l-c`, `soLoCo`, `someCom` (...)
  |===
  
  ==== Ambiguous Abbreviations
  When the user specifies input that can match multiple options or subcommands, the parser throws a `ParameterException`.
  When applications use the `execute` method, an error message and the usage help is <<Invalid User Input,displayed>> to the user.
  
  For example, given a command with subcommands `help` and `hello`, then ambiguous user input like `hel` will show this error message:
  
  