Those strings are defined in a 'parser.registry' dictionary, with expressions like

    self.register('action', 'store', _StoreAction)

(Users can also register their own custom classes. The registry can also be used for the 'type' attribute.)

So you can already do:

    parser.add_argument('--foo', action=argparse._StoreAction)

So I don't think we need another mapping like

    argparse.STORE_ACTION = argparse._StoreAction

I think these Action subclasses are not part of the API because users should never instantiate one directly.  It should always be done via the 'add_argument' method.

But on occasion it is handy to grab one of the Action objects when it is returned by add_argument, and display or even modify one of its attributes.  Some users are reluctant to do so because that's not documented.

Some of the `nargs` values have constants names in addition to the string values.  

argparse.REMAINDER = '...'
argparse.OPTIONAL = '?'
so on for '+', '*', and even '+...'.  Users almost always use the strings, while the code always uses the constant.

But because `argparse._StoreAction` is a class, with its own defined methods, there's never a need to test for its 'value' or identity.  So the code does not need a `argparse.STORE_ACTION flag.

So for end users, and for internal code use, the current use of subclasses and the registry is works, and doesn't need to be changed just to look more like other modules.