Romaji to Kana Converter: Astro — Chapter 3, Exercise 1
=====================================================================

TASK
Build sokuonLength exactly as this chapter describes, wire it into a
tokenizer, and verify it against three real words: "zutto" (ずっと,
all along), "issho" (いっしょ, together), and "matcha" (まっちゃ,
matcha). Then explain, in your own words, why checking for "ch"
specifically after a "t" has to happen before the general
doubled-consonant check runs -- what would go wrong if the order
were reversed?

SOLUTION

Running the wired-in tokenizer for real:

  console.log(tokenizeWithSokuon('zutto', 'hiragana'));   // 'ずっと'
  console.log(tokenizeWithSokuon('issho', 'hiragana'));   // 'いっしょ'
  console.log(tokenizeWithSokuon('matcha', 'hiragana'));  // 'まっちゃ'

All three verified correct. "zutto" and "issho" both trigger the
ordinary doubled-consonant branch (t followed by t, s followed by s).
"matcha" instead triggers the special "t" + "ch" branch, consuming
only the t and leaving "cha" for the ordinary tokenizer to pick up as
a real 3-character token, producing ちゃ.

The second half of this exercise is worth being genuinely careful
about rather than assuming the obvious answer. Swapping the two
checks and re-running an exhaustive comparison against every position
of "matcha," "zutto," "issho," and several other real and constructed
test words (including edge cases like "atchi" and "ttcha") shows
something worth stating precisely: the order does NOT actually change
the function's behavior on any input at all.

The reason is structural, not coincidental. The "t"+"ch" check only
fires when the character right after the "t" is "c". The general
doubled-consonant check only fires when the character right after the
current letter is an identical copy of it -- for "t", that means the
next character has to be another "t". Those two conditions can never
both be true at the same position, because "the next character is c"
and "the next character is t" are mutually exclusive by definition.
Whichever check runs first, the other one was never going to fire
anyway.

So the honest answer isn't "reversing the order breaks matcha" --
verified directly, it doesn't. The real reason to keep the "t"+"ch"
case as its own explicit, separately-stated branch is clarity and
future-safety, not a live correctness bug today: it documents a real,
irregular Hepburn exception as its own named rule rather than folding
it silently into the general doubled-consonant logic, so a future
change to either check (say, loosening the general rule to something
looser than an exact character match) can't accidentally create the
overlap that doesn't exist yet.

WHY THIS WORKS AS AN ANSWER
----------------------------
Rather than asserting a dramatic bug that a quick trace makes tempting
to assume, it actually swaps the order and tests it -- finding, for
real, that the two checks are mutually exclusive by construction, so
order has no effect on today's correctness. The value of keeping them
separate and ordered is honestly reframed as documentation and
future-safety rather than a currently load-bearing requirement.