parse("Smith, MD PhD").suffix returns "MD, PhD" — a comma the input never had

[derek73]

A space-separated run of post-nominals after a comma renders with a comma inserted between them, but only when the pre-comma part is a single word:

parse("John Smith, MD PhD").suffix   # -> 'MD PhD'    correct
parse("Smith, MD PhD").suffix        # -> 'MD, PhD'   a comma the writer never typed

Same for every run on that path:

input	.suffix today	wanted
Smith, MD PhD	'MD, PhD'	'MD PhD'
Smith, CBE MC	'CBE, MC'	'CBE MC'
Smith, BSc MBA	'BSc, MBA'	'BSc MBA'
Smith, PSM II	'PSM, II'	'PSM II'

The roles are right in all of these — only the rendered string is wrong.

The suffix view comma-joins its tokens unless a continuation token carries the stable "joined" tag, which only grouping applies (_group.py's joined_tags, consumed in _facade.py:357). The full-name path gets the tag; the one-word-family path does not. The same mechanism is recorded in docs/design/decisions.md's comma-suffix-arc as the reason phrase matching belongs in group rather than assign.

Reaches back to the one-word-family comma path added in #428 (#296 / #325).

Round-tripping is the visible cost: parse(str(parse(x))) is not stable, because the rendered comma re-segments on re-parse.

[derek73]

Measured on the 1.4.0 wheel, to head off a misclassification: this is an incomplete fix, not a regression. 1.4.0 never produced the comma-joined string because it never got the roles right in the first place:

1.4.0:  HumanName("Smith, MD PhD")   -> title='MD', first='PhD', last='Smith', suffix=''
1.4.0:  HumanName("Smith, CBE MC")   -> first='CBE', last='Smith', suffix='MC'
1.4.0:  HumanName("Smith, PSM II")   -> first='PSM', last='Smith', suffix='II'

#428 fixed the roles on this path; the render is the remaining half.