anchor.diff:  ==== Optionally Interactive
   Interactive options by default cause the application to wait for input on stdin. For commands that need to be run interactively as well as in batch mode, it is useful if the option can optionally consume an argument from the command line.
   
  -The default <<Arity,arity>> for interactive options is zero, meaning that the option takes no parameters. From picocli 3.9.6, interactive options can also take a value from the command line if configured with `arity = "0..1"`.
  +The default <<Arity,arity>> for interactive options is zero, meaning that the option takes no parameters. From picocli 3.9.6, interactive options can also take a value from the command line if configured with `arity = "0..1"`. (See <<Optional Values>>.)
   
   For example, if an application has these options:
   
  
positive.code: | @Parameters Field Type | Default Arity | Notes
  | boolean      | 1 |Positional parameters of type `boolean` or `Boolean` require a value. Only `true` or `false` (case insensitive) are valid values.
  | Single-valued type (e.g., `int`, `String`, `File`) | 1 | One parameter required for each position.
  | Multi-valued type (arrays, collections or maps) | 0..1 | For multi-valued positional parameters (arrays, collections or maps), values are optional, not required.
  |===
  
  
  
negative.code: When a `@Parameters` field is applied (because its index matches the index of the positional parameter), the field may consume zero, one or more arguments, depending on its arity.
  
  === Optional Values
  
  ==== Optional Option Parameters
  When an option is defined with `arity = "0..1"`, it may or not have a parameter value.
  
  The <<fallbackValue-annotation,fallback value>> determines what value is assigned when the option is specified without a value, while the <<defaultValue-annotation,default value>> determines what value is assigned when the option is not specified at all.
  
  ==== Optional Parameter Use Cases
  This feature is commonly used when an application wants to combine two options into one:
  the presence or absence of the option can be used like a boolean flag to trigger some behaviour, and the option value can be used to modify this behaviour.
  
  An example use case is an option that switches on logging when present, with an optional value to set the log level. For example:
  
  [source,java]
  ----
  @Option(names = "--syslog", defaultValue = "OFF", fallbackValue = "INFO",
    description = {
          "When specified without arguments, start sending syslog messages at INFO level.",
          "If absent, no messages are sent to syslog.",
          "Optionally specify a severity value. Valid values: ${COMPLETION-CANDIDATES}."})
  MyLogLevel syslogLevel;
  ----
  
  Another example use case is <<Optionally Interactive,password options>>.
  
  ==== Optional Parameter Limitations
  Be careful when defining commands that have both an option with an optional parameter and a positional parameter.
  
  [WARNING]
  ====
  The picocli parser is "greedy" when it handles optional parameters: it looks at the value following the option name, and if that value is likely to be a parameter (not another option or subcommand) then it will process the value as a parameter for that option. This may not always be what you want.
  ====
  
  For example:
  
  [source,java]
  ----
  class Ambiguous {
      @Parameters(description = "The file (required).")
      File file;
  
      @Option(names = "-x", arity = "0..1",
        description = "Option with optional parameter")
      String value;
  }
  ----
  
  When `-x VALUE` is specified on the command line, this results in an error: `Missing required parameter: <file>`.
  
  Users can use the <<Double dash (`--`),end-of-options delimiter>> and disambiguate the input with
  `-x &dash;&dash; VALUE`, but this may not be obvious to many users.
  
  An alternative is to avoid the use of optional parameters and use the default arity in this scenario to elimitate the ambiguity altogether.
  
  
  == Required Arguments
  === Required Options
  