homepage

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.