This is an example of using 'patch_w_mxg2.diff' to handle the inclusive group case proposed by the OP.

Since 'seen_non_default_actions' (and 'seen_actions') is a set of 'Actions', it is convenient to use 'set' methods with pointers to the actions that a collected during setup.  Tests could also be done with the 'dest' or other action attributes.

In this example I wrote 3 simple tests corresponding to the 3 proposed groups, but they could also have been written as one test.

    a_file= parser.add_argument("-o", "--outfile", metavar='FILE')
    a_dir = parser.add_argument("-O", "--outdir", metavar='DIR')
    a_pat = parser.add_argument("-p", "--outpattern", metavar='PATTERN')
    a_suf = parser.add_argument("-s", "--outsuffix", metavar='SUFFIX')
    ...
    def dir_inclusive(parser, seen_actions, *args):
        if a_dir in seen_actions:
            if 0==len(seen_actions.intersection([a_pat, a_suf])):
                parser.error('DIR requires PATTERN or SUFFIX')
    parser.register('cross_tests', 'dir_inclusive', dir_inclusive)
    ...

In theory tests like this could be generated from groups as proposed by the OP. There is one case in 'test_argparse.py' where a mutually_exclusive_group is nested in an argument_group.  But the current groups do not implement nesting.  A (plain) argument_group does not share its '_group_actions' list with its 'container'.  A mutually_exclusive_group shares its '_group_actions' but the result is a flat list (no nesting).

For now I think it is more useful to give users tools to write custom 'cross_tests' than to generalize the 'group' classes.