Proposed patches like this are supposed to be generated against the current development version (3.5...), especially if they are 'enhancements' (as opposed to bugs).  But there isn't much of a difference in argparse between 2.7+ and 3.4+ (except one nested yield expression).

Tests are in 'lib/test/...'

argparse does implement the '--' syntax.  That is, anything after it is understood to be positional, regardless of its prefix characters.  But before that, optionals and positionals can be freely mixed (within limits).

I agree that '--foo=one two' looks a lot more like an unknown optional than the test case 'a badger'.  Strings with '=' are tested earlier in _parse_optional.  

A fix that passes test_argparse.py and your example is:

        if '=' in arg_string:
            option_string, explicit_arg = arg_string.split('=', 1)
            if option_string in self._option_string_actions:
                action = self._option_string_actions[option_string]
                return action, option_string, explicit_arg
            else: # added for unrecognized
                return None, option_string, explicit_arg
                # or return None, arg_string, None

But the '=' case is also tested in the following line:

    option_tuples = self._get_option_tuples(arg_string)

The obvious difference is that _get_option_tuples handles abbreviations.

I wonder if the two can be refined to reduce the duplication, and handler your case as well.

There are other bug issues dealing with multiple '--', the mixing of optionals and positionals, and controlling whether abbreviations are allowed or not.  I don't recall any others dealing with strings that contain '=' or space.