parse("Smith, John V.") loses the middle initial — a dotted V after a comma reads as a generational suffix

[derek73]

parse("Smith, John V.")  # -> given='John', family='Smith', suffix='V.'
parse("Smith, John B.")  # -> given='John', middle='B.', family='Smith'

Same shape, and the only difference is that V is a roman numeral. Smith, John V. is an ordinary Western listing-format name with a middle initial, and the initial is currently lost to suffix.

The rule

A trailing period marks an abbreviation, which makes the word name material — an initial. That is why B. becomes a middle initial. V. should too.

A bare Smith, John V keeps reading as a generational suffix, because with no period there is no abbreviation and V genuinely can be the fifth.

This is the complement of #430, and the two share one boundary: inside a comma segment, a dotted I / V continues a suffix run (Smith, PSM I. → suffix PSM I.) but does not attach to a name (Smith, John V. → middle V.). What the previous word is decides it.

How it was found

Reported first as:

parse("John, Ma V.")  # -> given='Ma', family='John', suffix='V.'

Ma is period-gated ambiguous vocabulary, so bare Ma is correctly read as a name — and V. following a name should then be an initial. Probing showed the defect is not specific to ambiguous vocabulary; Smith, John V. is the general and much more common case.

Secondary observation

No ambiguity is emitted on any of these, though parse("John Smith V") does emit suffix-or-name for the same underlying question. The comma path appears blind to it.

Parity

Deviates from 1.4.0 deliberately. Measured on the wheel:

1.4.0:  HumanName("Smith, John V.")  -> first='John', last='Smith', suffix='V.'
1.4.0:  HumanName("John, Ma V.")     -> first='Ma',   last='John',  suffix='V.'
1.4.0:  HumanName("John, Ma B.")     -> first='Ma',   middle='B.',  last='John'

So 1.4.0 drew the same roman-numeral/other-letter split, and changing it needs a release-log classification and a differential ledger rule.