Romaji to Kana Converter: React & Next.js — Chapter 3, Exercise 3
=====================================================================

TASK
Explain, in your own words, why the check-order fix for the chōon
bug (checking for a continuation before attempting a normal token
match) is necessary specifically because every vowel is also a valid
standalone KANA_MAP key -- and why the analogous problem never came
up for the sokuon check in this same chapter.

SOLUTION

The chōon check has to run before the normal token-match loop
because there's a genuine collision between the two: a repeated
vowel letter, which should signal "extend the previous long vowel,"
is ALSO, on its own, a perfectly valid single-character key in
KANA_MAP (a, i, u, e, and o are all real standalone tokens). If the
normal match loop runs first, it will always find and accept that
valid single-character match before the chōon-check branch ever gets
a chance to run, because from the tokenizer's point of view nothing
about a lone repeated vowel character looks different from any other
letter that happens to also be a real token. The only way to give
the chōon interpretation a chance to win is to check for it before
the normal match loop is even attempted, so the "this is a
continuation, not a new character" possibility is considered first.

The sokuon check never runs into this same problem because doubled
CONSONANTS -- k, t, s, p, and so on -- are never themselves valid
standalone keys in KANA_MAP at all. There's no real token "k" or "t"
sitting in the table the way there's a real token "a" or "i". So even
if the sokuon check were moved to run after the normal match loop
instead of before it, the normal match loop would simply fail to
find anything for a lone consonant character (since no such key
exists), fall through to its own no-match path, and the sokuon logic
would still get a fair chance to run -- there's no valid alternative
match sitting there to steal the win the way a lone vowel steals the
chōon check's own opportunity.

So the real, structural reason is: vowels have a genuine double life
in this table (a real standalone token AND a potential chōon
continuation signal), while consonants used for sokuon detection have
no such double life at all. Check-order only matters when two
different interpretations are both genuinely reachable for the same
input character; for sokuon, only one interpretation was ever
reachable in the first place.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the real structural cause of the ordering requirement
-- vowels are simultaneously valid standalone tokens and valid chōon
signals, creating a genuine collision the normal-match-first ordering
loses -- and correctly explains why sokuon consonants never create
that same collision, since they were never valid standalone tokens
to begin with.