Should a comma turn off the glued-honorific peel? ("田中さん, 太郎" keeps さん in the family name)

[derek73]

#308 added a peel: a listed CJK honorific glued to the end of a name token is split off and routed to suffix. It runs inside script_segment, and therefore inherits that stage's two structural opt-outs — the family comma and the 间隔号. Neither gate was argued for the peel specifically; both came with the placement.

That produces a spelling disagreement of exactly the kind #308 set out to remove:

parse("田中さん 太郎")    # family 田中,   given 太郎, suffix さん
parse("田中さん, 太郎")   # family 田中さん, given 太郎          ← honorific absorbed

#308 treated this shape as a defect worth fixing elsewhere — ko_honorific_glued_given_trailing_suffix exists precisely so 김민준씨 Jr. and Dr 김민준씨, Jr. agree — and then left the identical disagreement standing under a family comma (ja_honorific_glued_family_comma). Two rows in the same table are pinned to opposite conclusions about the same phenomenon.

Why the gates may not be the peel's to inherit

Both gates answer where does a name divide into surname + given. AGENTS.md states the comma doctrine as "script-conditional behavior is ignored where a comma already decides the family", and the interpunct gate as "a divided name is a transcription — its pieces are syllable groups".

The peel does not ask that question. It asks a position-independent one: does this token end in a word that can never end a name? A comma elsewhere in the string does not change the answer, and the vetting behind GLUED_HONORIFICS is likewise position-independent. The peel is also explicitly not gated on segment_scripts for exactly this reason — the vocabulary carries its own license rather than borrowing the script's.

Measured, if the peel simply moves above both gates

田中さん, 太郎      family 田中さん, given 太郎     →  family 田中, given 太郎, suffix さん
田中さん, PhD       title PhD, family 田中さん      →  title PhD, family 田中, suffix さん
威廉·莎士比亚さん   given 威廉, family 莎士比亚さん →  given 威廉, family 莎士比亚, suffix さん
김, 민준씨          given 민준씨, family 김        →  unchanged

Four tests fail: the two stage tests pinning the gates, ja_honorific_glued_family_comma, and its facade twin.

The part that makes this design work, not a two-line move

Look at the last row. Under FAMILY_COMMA the name spans two segments:

"김, 민준씨"   structure FAMILY_COMMA   segments ((0,), (1,))   tokens ['김', '민준씨']

The peel scans segments[0] only. So moving the call fixes the pre-comma side and leaves the post-comma side glued — trading today's clean rule ("a family comma turns the peel off entirely") for a new asymmetry inside the comma case. Doing it properly means deciding what the peel's site is when the name spans segments, and for 김, 민준씨 the honorific is attached to the given name — a different question from the one the peel answers today.

Options

1. Leave it. Document the comma boundary as intended and reword the two rows so they stop disagreeing. Cheapest; keeps one simple rule ("a comma turns off everything script-conditional") at the cost of the spelling disagreement.
2. Move the peel above the gates and decide the multi-segment site question. Removes the disagreement for the pre-comma case; needs a rule for the post-comma one.
3. Lift the peel into its own stage between segment and script_segment. Makes the ordering structural rather than a comment and ends gate inheritance by construction. Costs: _PEELED_TAG becomes cross-module, _split/_longest_entry need a shared home, and "the one stage licensed to change the token count" becomes two.

Timing

2.1.0 is unreleased. If this lands before the release, no user ever sees the inconsistency; if it doesn't, option 1's documentation is needed so the boundary is at least stated rather than accidental.

Found by an altitude review on #311.