I've added a patch with tests that I think handles this case, without messing with existing test cases.  It adds a new 'space' test right before the existing one, one that explicitly handles an '=' arg_string.  

If the space is in the 1st part, it is marked as a positional (as it does in the existing code).  But if the space is in the argument portion has no such effect; the arg_string will be handled as an unknown optional.

        if '=' in arg_string:
            option_prefix, explicit_arg = arg_string.split('=', 1)
            if ' ' in option_prefix:
                return None
            else:
                return None, arg_string, None

The new testcase is in the TestParseKnownArgs class (near the end of test_argparse.py), and tests the different ways in which an arg_string can be allocated to a positional or unknown.

The underlying idea is that elsewhere in '_parse_optional()', an arg_string with '=' is handled just like a two part optional.  It first tries an exact match, and then tries an abbreviation match.  In that spirit, this space test also focuses on the flag part of the arg_string, not the argument part.

Much as I like this solution, I still worry about backward compatibility.  As discussed in 'http://bugs.python.org/issue9334', 'argparse does not accept options taking arguments beginning with dash (regression from optparse)', compatibility in this _parse_optional() function is a serious issue.  There the proposed patch adds a switch to the API.  But an API change is itself messy, and not to be taken lightly if it isn't needed.

This patch has some comments that should be stripped out before it is actually applied.  There is a quite a backlog argparse issues, so I don't expect quick action here.