I might accept a patch that tweaks the ArgumentDefaultsHelpFormatter class, but adding a parameter that must propagate through all the Action classes in just plain wrong.  

Users are confused by the many Action parameters as it is.  And based on StackOverFlow questions, I'd say there are lots of custom Action classes.  We cannot make a change that might break those!

One possibility is to tweak the `%(default)s` test to something like:

     if '(default` not in action.help:

Then the user who is not happy with the '%(default)s` display could just write a help like:

     help = 'my help text (default: mycustomvalue)'

In other words, embed the bypass mechanism entirely in the 'help' string and the Formatter class.  The mechanism would have to be something that is simple to explain, and be unlikely to interfere with existing uses of this Formatter.

And to play it safe, I'd suggest field testing a SmarterDefaultsHelpFormatter class first - one that implements a change like this, without touching the existing class.

Keep in mind that ArgumentDefaultsHelpFormatter is never essential.  The argparse developer can always add the '%(default)s` strings to selected 'help' lines.  He can even do this in utility functions that know more about the underlying program semantics.  I don't think this proposed enhancement gives the end user any added control.  

If you want to make a stronger case for this enhancement, find other cases where it would be useful.  So far you are just arguing that '(default= True)' for a 'store_false' Action may convey the wrong sense to users.  As r.david.murray argued, this problem can be minimized with a proper phrasing of the help string.

Another thought - 'store_false' is just a subclass of 'store_const'.  You could use that class instead with a different set of 'const' and 'default' values. e.g. ('Yes','No', or 'not-False', 'not-True').