Should `Doe, John MA` read `MA` as a credential, as 1.4.0 did, or at least report the fork?

[derek73]

After a family comma, a credential-shaped word at the END of the given part is read as a middle name, and nothing is reported.

>>> parse("Doe, John MA").middle
'MA'
>>> parse("Doe, John MA").ambiguities
()
>>> parse("Doe, John X.Y.Z.").middle
'X.Y.Z.'

The comma-less spelling of the same name does the opposite on both counts: John Doe MA gives suffix MA and reports suffix-or-name. So two writings of one name disagree about the reading and about whether a fork was called.

This is a 2.0-era reading, not a long-standing one. 1.4.0 read Doe, John MA as suffix MA. Every release from 2.0.0 through 2.3.0 reads middle MA, and 2.4 does not move it. Doe, John X.Y.Z. is middle in every release including 1.4.0.

What 2.4 changed nearby. The ambiguous credential class now reports at the trailing slot, at the first word after a family comma, in the part before a suffix comma, and in third-and-later comma segments. The given part's trailing slot is the one place it stays silent. PR #530 also retired an accident that had been reading some dotted words as suffixes, which moved a few names into this silent slot: Doe, John J.u.n.i.o.r. and Doe, John X.Y.I. went from suffix to middle, and John Smith nee Jones R.A.I. from suffix to maiden.

Two separate questions.

1. Should the words-to-spare rule apply at this slot, so Doe, John MA reads suffix MA again as 1.4.0 did? It has the words to spare: a family and a given name stand without it.
2. If the reading stays, should the slot at least report suffix-or-name? The argument against is noise: a word sitting where a middle initial sits may be a place nobody hesitates, which is the reasoning that keeps Smith, John V silent. The argument for is that the comma-less spelling reports.

The boundary is written down for now: AmbiguityKind.SUFFIX_OR_NAME's docstring names the slots it covers and this one it does not, and docs/design/decisions.md#S2 records the slot as open with these measurements.

Found during the review of #530.

[derek73]

Closed by #532.

The slot now reads and reports. parse("Doe, John MA") gives suffix MA, which is what 1.4.0 read and what John Doe MA has read all along, and parse("Doe, John Ma") keeps middle Ma. Either way the decision is reported as suffix-or-name, so the declined direction is visible too.

The noise question this issue asked was answered by measurement. Over a generated sweep of 78 comma / comma-less pairs (five listed members and two dotted tokens in three cased spellings each, plus five controls, against three name shapes), 48 pairs disagreed about whether the word was a credential or a name, every one in the same direction: the comma form declining what the comma-less form took. After the change 3 disagree, all three the lower-case do rows that rules.md#P6 owns by design. tests/v2/test_properties.py carries the sweep with those three as a closed allowlist, so a fourth exception fails.

Only one half has a 1.4.0 parity claim. Doe, John MA restores 1.4.0's role and adds the report. Doe, John X.Y.Z. was a middle name at 1.4.0 too, so reading it as a suffix is a new divergence, taken to match John Doe X.Y.Z. and recorded as an accepted cost.

do is the one class member that is also a surname particle: capitals decide, and the particle rule keeps every other spelling. Doe, John DO reads suffix DO; Doe, John do, Doe, John Do and DOE, JOHN DO attach to the family as before and report particle-or-given. A one-case record cannot tell SMITH, JOHN DO from NASCIMENTO, EDSON ARANTES DO, and both read as the particle: right about the second, wrong about the first. Accepted, and the report is how a caller finds it.

Not reached, and asked separately: in Doe, Jane nee Smith MA the maiden clause takes Smith MA whole, so that MA is still read in silence.

The rule is rules.md#S2 and #P6; the reasoning is under S2 and P6 in docs/design/decisions.md.