Should a family read as two surnames split into particles and base per surname? Juan Pérez de la Vega reads family_base 'Pérez Vega' #1022

Part of #754 (phase 4, the output model). This is the item decisions/R10 leaves Open: "a view for the first unit and its name ... with the per-unit particles and base CLDR's surname-prefix and surname-core would need". The vocabulary-model RFC's render-pattern table names it as the one gap between our views and CLDR's fields.

When: rules/O6 (two_family_names) has read the family as two surnames, as in Juan Pérez de la Vega.

Then: the first surname gets a view of its own, split into particles and base the way family_particles and family_base split the whole family. The second surname stays as surname2. Placeholder names are used below; naming is an open question.

• Juan Pérez de la Vega → first surname 'Pérez', its particles '', its base 'Pérez'; surname2 'de la Vega'
• Juan de la Vega del Valle → first surname 'de la Vega', its particles 'de la', its base 'Vega'; surname2 'del Valle'
• Gabriel García Márquez → first surname 'García', its particles '', its base 'García'; surname2 'Márquez'
• A family read as one surname: the first-surname views equal family, family_particles and family_base, so nothing moves. Examples: Juan de la Vega, and any parse without two_family_names.

Because:

• CLDR's surname-prefix and surname-core describe the first surname only (UTS More suffixes  #35 part 8), and CLDR has no prefix field for surname2. A render pattern a language pack carries (Phase 4: order and shapes, the rules a pack can choose, and the output model #754, decided 2026-10-28) fills those fields, so it needs this split.
• A base that joins words from two surnames is nobody's name. Pérez Vega and Vega Valle sort and abbreviate wrongly wherever a caller reads family_base as "the surname to file under".
• vCard (RFC 9554's second surname in N) and FHIR (humanname-fathers-family / mothers-family) keep the two surnames apart in the same way.

Today (Parser(policy=Policy(two_family_names=True))):

Except:

• No first surname is told apart where O6 does not read two surnames. That covers a family comma (Pérez de la Vega, Juan) and a family that already holds two words (Juan de la Vega Pérez, José Ortega y Gasset). In those shapes surname2 is empty today and the family is one unit, so its base stays 'Vega Pérez' / 'Pérez Vega'. Whether these shapes should be read as two units is R10's other open question and is not decided here.
• A connective or hyphen inside the family (Ortega y Gasset, García-López) is left to that same open question.

Measured 2026-11-02 over tools/differential/cldr_fields.jsonl (CLDR 48 sample renderings, nearly all fictional). 660 renderings state surname-core. 369 of those (123 distinct names) also state a surname2, e.g. von / Brühl + González Domingo. That is the population this split serves. Today cldr_agreement.expected_roles works around the gap by appending surname2 to the expected family_base ("Brühl González Domingo"). With a first-surname view the scorer could compare CLDR's core directly. GND (259 core renderings) states no second surname, so it is unaffected.

Open questions:

1. Names. R10 floats surname for the first unit, which sits next to the existing surnames (middle + family). Options:
   • surname / surname_particles / surname_base
   • surname1, to pair with surname2
   • family_particles / family_base narrowed to the first surname when there are two. This moves an existing view, so it needs a rule change and a release-log bullet.
2. Should initials() keep reading the whole family's base, which gives J. P. V. for Juan Pérez de la Vega today? CLDR's monogram uses the first surname only.
3. Does the view join render() keys and the snapshot's recorded views, as surname2 did? (R10 kept surname2 out of as_dict(), --json, comparison_key() and the repr.)

Excluded: which particles belong to the base is a separate question and is not this issue. Today every particle is set aside: Jean de La Fontaine has base 'Fontaine' where French files under 'La Fontaine', and Mary Van Buren has base 'Buren' where American usage files under 'Van Buren'. That question is a property of a particle reading chosen by language, and gets its own issue. Related: #939 (a connective inside an all-particle family), #1013 (render one field as initials), #670 (leading van den under a family-first order).