Right now "type" has a clear and understandable action of invoking a callable.   Imbuing "type" with other semi-magical capabilities opens a new can of worms.

Unless some persuasive new commentary appears in the next few days, I'm going to close this feature request and the associated PR.

At some point, we should consider adding a recipes/faq section to the docs.  That would help people bridge from their goals to the actual capabilities offered by the module.

Also, we should make strong suggestions about the separation of responsibilities between the parser and the downstream code that acts on the parsed variables (much like the discussion in the templating world about keeping business logic outside of the template and instead focusing on formatting logic).

For the case at hand, there are several ways to go:

      # Proposed new magic with hard-wired
      # truthy/false words: yes True 1 true Y si oui ...
      parser.add_argument("--mybool", type='bool')

      # Existing capability where the user controls
      # exactly which logic to apply
      parser.add_argument("--mybool", type=str_to_bool)

      # Existing capability with downstream processing
      parser.add_argument("--mybool", choices={'True', 'False', 'Yes', 'No'}
      args = parser.parse_args()
      mybool = args.mybool in {'True', 'Yes'}

      # Existing capability with explicit flag arguments
      # (the highly upvoted "canonical" solution StackOverflow)
      parser.add_argument('--feature', dest='feature', action='store_true')
      parser.add_argument('--no-feature', dest='feature', action='store_false')
      parser.set_defaults(feature=True)