addParameter adds a Parameter/Value pair to the input syntax of your function. For example, if you had a function called myFunction in which you were using the input parser:

addRequired(p,'x')
addParameter(p,'Foo',1)

Would add:

myFunction(x,'Foo',value)

As a valid syntax with a default value of 1. In parameter value pairs, the name of the parameter is specified with a string or character array, followed by a value specification.

addOptional(p,'Foo',value)

Would add:

myFunction(x,value)

As an optional positional argument. In this case, you only specify the value of the optional argument without specifying a parameter name.

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.

The problem is that validatestring returns the matching string from the cell argument ({'imag',''}) rather than a Boolean indicating if it passes validation. Instead, use strcmp and any:

@(x) any(strcmp(x,{'imag', ''}))

Also, with validatestring, if the input string did not match either 'imag' or '' (actually just 'imag' since empty strings only match in R2014a+), it would throw an error rather than returning false so that the inputParser could return the appropriate error.

Another nice way to fix the problem is to change the syntax of applyFunc entirely so that instead of just 'imag' as an optional string input argument, use a Parameter-Value with 'imag' as the parameter and a validated boolean as the input.

The input definition suggested by Amro in the comments:

p.addParameter('imag', false, @(x)validateattributes(x, {'logical'}, {'scalar'}))

The usage:

mysum(x,'imag',true)
mysum(x)               % default is equivalent to mysum(x,'imag',false)

This would simplify the rest of the code with p.Result.imag being a logical scalar. I would suggest:

x = f(v) + p.Result.imag*1i;