The parser's Western-order assumption is confined to the positional assignment loops in parse_full_name — the vocabulary layer (titles, prefixes, suffixes, conjunctions, nicknames, capitalization) is entirely order-agnostic, and the lastname-comma path already parses family-first when a comma provides the signal. That makes name order configurable without restructuring the parser.

Proposal: an opt-in Constants attribute specifying the positional order of name parts, e.g.:

A boolean family_name_first flag was considered and rejected: Vietnamese order is [family][middle][given] — the given name is the last token — so these issues need at least two non-Western orders. An order spec covers both and subsumes the Western default as ('first', 'middle', 'last').

Notes for design:

• Must be opt-in config, never auto-detected: "Tham Jun Hoe" is token-for-token indistinguishable from a Western 3-token name.
• patronymic_name_order (v1.3.0, last name + first name + optional patronymic, Russian name order #85) is the architectural precedent for an opt-in flag reassigning first/middle/last.
• Design decisions needed: interaction with comma formats (a comma is an explicit signal — probably overrides the spec), whether suffix/roman-numeral detection still peels from the string end, and how title position is treated.
• Compound given-name boundaries (Weak Arabic Name handling #133/Add a feature to work with Hispanic and Portuguese names (latinos) #103) are not made easier by this — same ambiguity, different position.

Would resolve the spaced-input cases of #83 and #146.