Are the custom stat-related values required parameters now? They should be be optional, IMO

Sure, they should be optional

I think this should be private

Clarification: maybe I should not put this class in this file. I meant for it to be public so that user can easily enter input. They have more than just the callable: e.g. percentile requires 1) an array of data and 2) and int. While the array data is drawn from main input , we need to put the integer argument in this object. Furthermore, each function drawn on the violin has to have a corresponding artist object returned by the function _Axes.violin() so we need an "alias" there as well. While each function input alias should be unique, I tried to be defensive by dealing with duplicating alias as discussed below. In short, this is a wrapper object that specifies everything that a callable to be drawn on the violin should know (apart from the array data input, which is drawn elsewhere). Happy to discuss/modify more if required.

using "kwargs" instead of "kargs" would be more consistent with the rest of the MPL code base

Noted

Any iterable should be fine. Or, at the very least, tuples should be valid as well.

So something like:

if np.isscalar(self.optional_args):
    self.optional_args = [self.optional_args]

Noted.

does this need to return unique_alias_set?

No. unique_alias_set keeps track of all alias so far. The actual alias (modified so that they are unique) is in the ViolinStatFunc object itself. I think this defensive programming mechanism helps safe-guarding against user inputs where multiple input functions have repeating aliases. These aliases later on become the keys in the dict of artist object returned by violin function. While never experimented with it myself, I assume these artist object allows user to modify colors, shape and other visual effect of the line drawn on the violin. Thoughts?

unique_alias_set isn't used or defined anywhere else, so I'm not sure why we even need the aliases. Why can't the user just pass a list of functions that accept an array as input and returns an array or scalar, and draw lines at each value? For instance, the user would provide:

from functools import partial
stat_fxn = [partial(np.percentile, q=[5, 25, 50, 75, 95])]
# OR
stat_fxns = [np.mean, np.median, partial(np.percentile, q=95)]

## Then somewhere in the new code, we'd do something like:
results = np.flatten([stat(data) for stat in stat_fxns])  # not sure that flatten is the right function

should work.

In general, I guess I'm saying I'd like to see an API that let's the users work with familiar functions, rather than having to the learn the nuances of a new class

Ah. I see where you are coming from. Will remove this new class. I'm only worried about the very final output i.e. the artist dictionary output of _Axes.violin(). Where I'm coming from is that the _Axes.violin() outputs a dictionary of artist, and we need unique dictionary keys to represent the artist corresponding to the custom statistics function.
These artist objects allow user to change color, shape of the line etc... and the dictionary requires a unique key i.e. my current implemented alias. We have three ways of going around this:

1. (non-user friendly) make user input a list of dictionary where each dictionary has a callable and an alias and constraint that all aliases in the list of dict are unique
2. (slightly better) make user input the same list of dictionary but alias doesn't need to be unique, we modify the duplicating alias internally (as I did above with the resolve_duplicate_aliases and let them know we modify some aliases.
3. (probably fits where you are going with) don't ask for alias at all, and we make our own alias internally in the order that user input, but we still have to let them know the aliases.
   Let me know what you think. I'm open for suggestions.

if _ViolinStatFunc is private, then we can only deal with callables and simplify this logic.

Discussed above.