So in the big picture, the purpose of this change is to treat the inputs like a kind of state-machine.

In the bigger example, the `**` positional values are processed one by one, using the interspersed optionals to set state parameters.

`args.sources` then ends up as a list of dicts, each of the form:

    {'name': 'input3.txt', 'frobnicate': None, 'massage_level': 5}

where 'name' is the positional value, and 'frobnicate' and 'massage_level' are the latest values (default or user supplied).  The optionals can be specified in any order or repeatedly.

While the proposed change to the core parser is (apparently) minor, it does occur at the center of the action.  That is not the place we want any (new) bugs or backward incompatibility.  And the full implementation requires a new Action subclass that is quite different from existing ones.

Given how different this is from the normal argparse parsing (and the POSIX parsing argparse seeks to emulate), I question the wisdom of adding this, in part or whole, to the stock distribution.  It could certainly be published as a pypi.  That already has a number of  parsers, some built on argparse, others stand alone.

I also wonder whether it would be simpler to do this kind of parsing directly from sys.argv.  Just step through that list, consuming the values and flags in sequence.  

Sorry to sound like a wet blanket, but I've seen too many seemingly innocent patches that caused unforeseen problems down the line.