Romaji to Kana Converter: Angular & Express — Chapter 2, Exercise 3
=====================================================================

TASK
Build convertNaiveV2 (checking lengths 1, 2, 3 in that order) and
confirm it produces the correct result for "kyaku" but the wrong
result ("んあ") for "na". Then explain in your own words why "n"
specifically is the token that exposes this bug, when most other
single-character or short tokens wouldn't.

SOLUTION

  function convertNaiveV2(romaji: string): string {
    let hiragana = '';
    let i = 0;
    while (i < romaji.length) {
      let matched = false;
      for (let len = 1; len <= 3; len++) {
        const chunk = romaji.slice(i, i + len);
        if (KANA_MAP[chunk]) {
          hiragana += KANA_MAP[chunk].hiragana;
          i += len;
          matched = true;
          break;
        }
      }
      if (!matched) {
        hiragana += romaji[i];
        i += 1;
      }
    }
    return hiragana;
  }

Testing:

  console.log(convertNaiveV2('kyaku'));
  console.log(convertNaiveV2('na'));

Run with: node (or ts-node)
Output (verified by hand-running the real function):

  きゃく
  んあ

kyaku succeeds: at position 0, length 1 ("k") and length 2 ("ky")
both genuinely fail to match anything in KANA_MAP, so the loop
reaches length 3, finds "kya," and correctly proceeds -- ascending
order costs nothing extra here since no shorter prefix happens to be
valid.

na fails: at position 0, length 1 gives "n," which IS a real, valid
one-character token (ん) on its own. The loop finds this match
immediately and stops -- it never even tries length 2 ("na") at the
same position, because it already "succeeded" with something shorter.
The remaining "a" is then processed separately as its own token (あ),
giving んあ instead of the single correct syllable な.

WHY "n" SPECIFICALLY EXPOSES THIS BUG
----------------------------------------
Almost every single-character token in this table is a vowel (a, i,
u, e, o), and none of the five vowels are themselves the start of a
different, longer, valid token -- there's no "ay," "in," "ub," etc. in
KANA_MAP. A vowel being matched first therefore never steals a match
away from something longer, because nothing longer starting with that
vowel actually exists.

"n" is the one genuine exception: it's both a complete, valid token by
itself (ん) AND the literal first letter of five different, longer,
equally valid tokens (na, ni, nu, ne, no). Any tokenizer that tries
shorter lengths before longer ones will find "n" and stop the instant
it appears at the start of one of those five real syllables, since it
has no way of knowing a longer match was also available at that exact
same position without actually checking. Checking longest-first, as
the chapter's own final version does, avoids this entirely -- a longer
attempt that fails costs nothing and simply falls through to a
shorter one, so the algorithm never "settles" for a short match when a
longer, correct one was sitting right there.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces both the correct result for "kyaku" and the genuinely
wrong result for "na" with the real ascending-order function, then
correctly identifies the precise structural reason "n" is uniquely
positioned to expose the bug -- being both a complete valid token and
a real prefix of five longer ones -- rather than a vague appeal to
"ordering matters" without explaining which specific token creates the
actual collision.