Should a family name that is all particles have an empty family_base? (parse("Anh Do").initials() == 'A.' — the surname vanishes) #385

Rationale

family_base exists so callers can address the surname without its particles (rules.md#R2) — sorting wants "Vega", display wants "de la Vega". The v1-era design held that a family name can never be only particles: "Anh Do" is the canonical case (Do is a common Vietnamese surname and a listed ambiguous particle), so last_base was guarded non-empty whenever last was non-empty. That guard survives in exactly one of the two APIs.

Current state (measured, 2.2.0dev)

The observable harm on the core side: parse("Anh Do").initials() == 'A.' — initials take the first letter of each given, middle, and base family word (rules.md#R3), so an all-particle family contributes nothing and the surname disappears from the initials.

No issue, decision record, or spec records whether the core's drop of the guard was deliberate; the divergence surfaced in the PR #381 spec-residue sweep and is held as decisions.md#R2, intent UNVERIFIED. The facade side is v1 parity either way.

Options

1. Restore the guard in the core view — when every family word is a particle, family_base is the whole family and family_particles is empty (the facade's reading). Fixes the initials loss; rules.md#R2 gains the boundary, and the "Anh Do" → family_base="" example flips to a deviates: marker until it lands. Cost: a behavior change on the 2.x core, release-log-classified.
2. Bless the core's reading — an all-particle family genuinely has no base; callers wanting the whole thing have family. The initials loss becomes an Accepted consequence on rules.md#R3 (arguably defensible: initials of "van der" are nonsense anyway — but "Do" is not "van der"). Cost: the facade and core permanently disagree on the same input, which FACADE-CONTRACT would need to carve out explicitly.
3. Guard the view only when a word is vocabulary-ambiguous — "Do" (a real surname) anchors the base; "van der" (never-given particles) stays empty. Most faithful to the domain, but it makes family_base consult the never-given/ambiguous line (Mc Donald and Ste Marie read the particle as the given name #360's contested territory) and splits the two rows of the table above.

Open

Whether any of the three readings should also change what family_particles reports for the anchored word — under option 1 and 3, is "Do" a particle at all once it's the base?