In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't allow optionals within positionals"

we added new parsing functionality by defining a new parser method:

parse_intermixed_args

It added functionality without requiring a new parameter for the parser (no point in confusing users with parameters they don't need or understand).  It was also a good fit because it worked on top of the default parser, fidling with the nargs to parse positionals and options in different runs. 

I would like to see something similar for this problem.  Define a

parser.parse_opt_args() method 

that tries, as much as possible to follow the optparse strategy.  As I commented previously, the difference in behavior starts at the top.  

argparse distinguishes between flag (optiona) and argument strings based on the dash(es), and then allocates strings to the Actions based on that pattern and nargs.  It also alternates between handling positionals and optionals.

optparse passes all the remaining strings to an Action, lets it consume what it wants, and resumes parsing with the remainder.  It does not handle positionals; those are just accumulated in an 'extras' list (sort of like parse_known_args without any defined positionals).

An unknown in this approach is whether the argparse.Action class(es) can be adapted to this 'consume what you want' strategy.  It would be nice if such an alternative parser could be written that doesn't require any changes to the Action.  We don't have to go so far as to allow custom Action classes that imitate optparse Options.

But I haven't thought about this problem since 2013.  I don't sense either, from other bug/issues, or Stackoverflow questions, that this is a pressing need.