I do not recommended the use of inputParser with optional arguments that are allowed to be character arrays, because parse() cannot distinguish if the user passes a parameter name (which is always of type char) or the optional input argument. Thus, it is a logical consequence of this behaviour why you cannot pass a char as an optional input argument.
However, if you specify a validation function for the optional input arguments that may be char, you can make it work. From the addOptional documentation under section ‘Tips’:
For optional string inputs, specify a validation function. Without a validation function, the input parser interprets valid string inputs as invalid parameter names and throws an error.
This is the error your example generated.
Fixing your example
'o' is the optional input argument. If you know how to validate the values 'o' needs to accept, provide a validation function that returns true for those valid inputs. For example, if you know 'o' will always be a char array, try the following (line by line).
a = inputParser;
addOptional(a, 'o', 'default', @ischar);
addParameter(a, 'p', 1);
parse(a, 'x'); % OK
parse(a, 'Hello, World!', 'p', 2); % OK
parse(a, 'p', 'p', 'p') % OK, although quite cryptic
parse(a, 3); % Throws an error, as expected, because 3 is not a char
parse(a, 'p', 4) % Throws a somewhat unexpected error, because we meant to set parameter 'p' to value 4
The last line seems counter-intuitive, but it's not! We'd expect the parser to detect the parameter 'p' instead of implicitly assuming it is the character we provide for optional argument 'o', which we wanted to omit. It is the expected behaviour, though, as I will explain now.
Why char optionals give inputParser a hard time
The demonstrated bahviour is expected because both the optional and parameter arguments are not required, i.e., optional. If you'd have two optional input arguments, 'o1' and 'o2', their order matters to the input parser (which is why the MATLAB documentation calls them ‘optional positional arguments’). You could never pass a value for 'o2' before a value for 'o1'. This implies 'o2' can only be used if 'o1' is also specified. In other words, 'o1' impedes the use of any other optional arguments.
The same is true for parameters, which should always come after other optional input arguments (as you already quoted). As such, they behave like optionals if any optional input arguments are allowed to be char. The result is MATLAB's inputParser not knowing if a char input is an optional input argument or a parameter. MATLAB's developers have decided to require explicit ordering of optional inputs, so MATLAB can be sure what optional arguments are passed to parse().
Suggested action if optional inputs may be char
Because using optional input arguments requires MATLAB to assume some input arguments referring to an optional input argument, others referring to parameters, this may result in errors, behaviour or results unexpected by the end-user if not all optional arguments are specified.
Input argument schemes are better if written explicitly to prevent this unexpected implicit behaviour. I suggest that if optional input arguments are required that accept char input, you always make them parameters, i.e., name-value pair arguments using addParameter. Using optional input arguments that accept char input only works if not using any parameters, or by explicitly stating (e.g. in the help) that parameter input argument can be used if and only if all optional input arguments are given as well.
