Should Elizabeth II, Queen read Elizabeth as the given name, the way Queen Elizabeth II does? #720

The question

rules/H1 (a title and one name word) says a title in front of a single name word makes it the family name, "unless the title is a given-name title, which keeps it the given name". O5 (the lone name word's convention) says this holds after a comma too: "A comma with only a TITLE after it names no family either, but the title still decides the field wherever it stands." The parser does not do that. When the only thing after the comma is a title, a single name word before the comma becomes the family name whatever the title is:

The rules disagree with each other as well as with the code. C1 (the suffix-comma decision) says a part after the comma holding "titles and suffixes only, fixes no family boundary", but the only consequence it states is the one for a part before the comma with MORE than one name word. Its example Smith Jr., Mr. → family Smith implies that a single word before the comma is the family. With Mr., H1 gives the same answer. With a given-name title it gives the opposite, and no rule says which one wins.

Why nothing pins this today

The only row that showed H1's reading behind a comma was John V, Sir (given John, suffix V). It read that way by accident, not because of H1:

• _comma._whole_name (nameparser/_pipeline/_comma.py:149) does C1's count before the comma using is_suffix_piece. That predicate vetoes an initial-shaped V, so V counts as a name word. John V is two words, which makes the structure SUFFIX_COMMA and gives segment 0 the positional read: given John, then V read as the generation.
• H1's site in post_rules only ever retags given → family, and only when the family is empty. It never moves a word into given. So its given-name clause means "decline to retag", and the clause holds only where assign has already put the word in given. For John III, Sir, III is suffix vocabulary, the count finds one name word, the structure is FAMILY_COMMA, and assign writes John to family before H1 runs.

PR #719 (#718, S10, the trailing roman numeral) reads that lone V as the family name, so John V, Sir is now given John, family V. The row was renamed comma_path_given_name_title_behind_a_listed_numeral on John III, Sir, and its notes record the reading against H1.

The same accident still happens on PR #719 for a numeral that has its shape but is in no vocabulary list: John VI, Sir reads given John, suffix VI, while John III, Sir reads family John. Today the reading depends on how the numeral is spelled (on master V, I and X behave like VI). No row covers VI.

Proposed rule (option A: H1 decides)

Rationale: a comma with nothing but titles after it does not divide family from given. There is no given part, so the comma says nothing about which field the word before it fills. C1 already says this about the boundary, and O5 already says it about the field. That leaves exactly H1's case: a title and one name word, with the title written behind the word. H1's rationale already covers a title written on the other side of the name (Smith Sir. → given Smith). A comma between the two should not change what the title addresses by.

Statement (amends H1; C1 gains the matching clause for one name word): where the part after a comma is titles only, the one name word before it is read by H1 as if no comma stood there. A title that addresses by surname makes it the family name, and a given-name title keeps it the given name, whatever suffix stands beside it.

"Elizabeth II, Queen"       →  given="Elizabeth"
"John III, Sir"             →  given="John"
"John Jr., Sir"             →  given="John"
"John, Sir"                 →  given="John"
"Anne, Princess"            →  given="Anne"
"John III, Dr."             →  family="John"  · boundary
"Smith Jr., Mr."            →  family="Smith"  · boundary
"Smith, Sir John"           →  family="Smith"  · boundary
"John Smith III, Sir"       →  family="Smith"  · boundary

Accepted: a listing record whose given field holds only a title (Smith, Sir, a CSV row with the given name missing) reads given Smith with the family empty, the way Sir Smith reads. The input names one word and one title, and the title is the only evidence there is. This is H1's existing Accepted clause ("a given-name title plus one name word leaves the family empty") at a new site. It departs from 1.4.0, which read last John for every row above (John V, Sir as last John V).

Mechanism sketch, not a design: what assign needs is a family comma whose part after the comma is titles only, with one name word before it. Assign must read that segment as it reads a comma-less name, so H1's guard can see an empty family. Or H1's site needs a family → given direction for that structure. Either way, the VI/III split goes away, because both spellings reach H1.

Option B: the comma decides

Keep the code. Amend H1's statement, O5's "the title still decides the field wherever it stands" sentence and C1, so that they say a word standing alone before a comma is the family name even under a given-name title. That keeps 1.4.0 parity. It still leaves the VI spelling reading given, and under B that is a defect to fix: C1's count and the walk read VI two ways, the "group-side predictor disagrees with the walk" class in AGENTS.md's Gotchas.

Open questions

1. A or B? A follows the docs as written and the comma-less mirror (Smith Sir. is an H1 example). B follows 1.4.0 and the Smith, Sir CSV reading. Recommendation: A. The regnal shape Elizabeth II, Queen is the form library catalogs use for royal headings (LCNAF writes Elizabeth II, Queen of Great Britain; not checked this session). Under B the row that pins the rule would pin a reading against H1's own sentence.
2. Should a numeral beside the word count as evidence? A regnal numeral sits on a given name and a generational Jr. sits on a surname (Smith Jr., Sir). This proposal does not split on it. The III in John III, Sir could be either kind, and the parser cannot tell them apart.
3. Family-first orders show the same one-directional mechanism: under FAMILY_FIRST and FAMILY_FIRST_GIVEN_LAST, Sir John reads family John, since H1 cannot undo assign's placement. This is recorded only in the notes of the given_name_title_plus_one_word_with_maiden row in tests/v2/cases.py, not in H1. Suggest leaving it out of scope here, but H1's statement has no order qualifier, so it is a second place where the rule says more than the code does.

Exclusions

• No vocabulary change. Which titles address by given name stays given_name_titles (Should Prince Harry read Harry as a given name? (prince, princess, lord, lady are titles but not given-name titles) #519).
• Not the three-part shape Scott, Walter, Sir (C2, a part past the second comma).
• Not Elizabeth II, Queen of Great Britain, which reads title Queen of Great, given Britain (a connective-join problem), and not John XXIII, Pope, where XXIII is past _ROMAN's I–X and reads as the family name.

Measurements (2026-10-18)

• Tree: master 958d252 and PR Read a lone V, I or X after a first name as the family name (#718) #719's head ed64d54, in a detached scratch worktree. The rows above are identical on both, except John V, Sir/John V, Dr./Sir John V/John I, Sir/John X, Sir, which Read a lone V, I or X after a first name as the family name (#718) #719 moves.
• Structure, by stepping STAGES and reading state.structure after group: John III, Sir → FAMILY_COMMA; John VI, Sir → SUFFIX_COMMA.
• 1.4.0 (PYTHONSAFEPATH=1 uv run --isolated --no-project --with nameparser==1.4.0 from a scratch dir, __file__ asserted under site-packages): John, Sir, John III, Sir, John Jr., Sir, John PhD, Sir, Elgar, Sir → last = the word; John V, Sir → last John V; Sir John → first John.
• Orders: under all three orders, John, Sir and John III, Sir read family John.
• Corpus: none of the 1,465 distinct comma names in tools/differential/corpus*.jsonl has a given-name title opening the part after the comma (not even Smith, Sir John). So option A is expected to move no snapshot name beyond the new rule examples. Re-measure on the implementing branch.