Kuromoji romaji readings drop the small tsu before g, z/j, d, b and h/f, so バッグ (bag) and バグ (bug) both become "bagu"

Kuromoji's JapaneseReadingFormFilter can replace each token with its reading in romaji (useRomaji=true, opt-in). Its romanizer, ToStringUtil.getRomanization, is documented as "Romanize katakana with modified hepburn", and Hepburn writes the small tsu ッ by doubling the next consonant. The method does that only before the カ, サ, タ and パ rows (キット kitto, マッチ matchi); before any other kana its case 'ッ' falls through and writes nothing. So common loanwords lose the ッ: バッグ (bag) becomes bagu, the same term as バグ (bug), ベッド becomes bedo, キッズ becomes kizu like キズ. Distinct words then match each other, and a romaji query typed baggu finds no document with バッグ. There is no error and no index damage. It has been so since the method was written in 2012, in every release from 3.6.0 to 10.5.2 and on main; a fix changes indexed romaji terms, so such fields need reindexing.

• Small tsu (sokuon, ッ): a doubled consonant. キット (kit) is ki-tto, バッグ (bag) is ba-ggu. Hepburn writes it by doubling the consonant that follows, tch before ch (マッチ matchi).
• JapaneseReadingFormFilter: replaces each token with its reading, in katakana (the default) or, with useRomaji=true, in romaji. For a dictionary word it romanizes the reading, for an unknown word the term text, by calling ToStringUtil.getRomanization (JapaneseReadingFormFilter.java:80-88).
• ToStringUtil.getRomanization: a public static method, documented "Romanize katakana with modified hepburn" (ToStringUtil.java:240, :251). It walks the string once with a lookahead of two characters and a switch on the current character.

1. For ッ the method looks at the next character in an inner switch (ToStringUtil.java:264-295). It has cases for カキクケコ (k), サシスセソ (s), タチツテト (t) and パピプペポ (p), each appending the letter and leaving with break main.
2. Any other next kana matches no case, leaves the inner switch and reaches the outer break, which appends nothing. The next iteration romanizes the following kana as usual.
3. So バッグ is バ ba + ッ (nothing) + グ gu = bagu, while キット is キ ki + ッ t + ト to = kitto.
4. The filter writes that string into the term. Positions, offsets and the token count do not change; only the term text does.

On main: バッグ → bagu (expected baggu), ベッド → bedo, ビッグ → bigu, キッズ → kizu, ブリッジ → buriji, スタッフ → sutafu, バッハ → baha: 7 of 7 wrong, while キット kitto, キップ kippu, ザッシ zasshi and マッチ matchi are right. Through the filter, バッグ and バグ both give the term bagu, and the typed query baggu stays baggu. In the security screen's 3,022-document probe index (random sokuon-heavy text), the term query baggu matched 0 documents on stock main and 116 with the generic fix shadowed in.

• Who. Users of JapaneseReadingFormFilter(input, true) or of the SPI factory japaneseReadingForm with useRomaji=true (default false, JapaneseReadingFormFilterFactory.java:44-50; its javadoc shows the Solr schema form, :26-34), and direct callers of ToStringUtil.getRomanization (package ja.dict is exported, module-info.java:25).
• What triggers it. Ordinary loanwords with ッ before g, z/j, d, b or h/f: バッグ, ベッド, ビッグ, キッズ, グッズ, ブリッジ, スタッフ, ヘッド, ドッグ, バッハ. No special input and no scale. How often such words occur in real text was not measured.
• Two symptoms. Minimal pairs collide (バッグ/バグ → bagu, キッズ/キズ → kizu), so each matches the other; and romaji queries spelled with the doubled consonant (baggu, beddo) analyze to themselves, so they miss the indexed bagu and bedo (run as an index query for baggu: 0 hits).
• Inconsistent output. The same method writes kitto and matchi, so users cannot predict when the doubling applies.
• Silent. No exception, no log line, no index damage (CheckIndex clean in the security probe).
• How likely. Romaji mode is opt-in and rarely used, and the romanizer is already lossy by design (it drops the long-vowel mark ー, so ビール and ビル share a term); nobody has reported this since 2012.
• After a fix these words get new romaji terms, so existing romaji fields must be reindexed.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => org.junit.ComparisonFailure: expected:<bag[g]u> but was:<bag[]u>
       org.junit.Assert.assertEquals(Assert.java:117)
       org.junit.Assert.assertEquals(Assert.java:146)
       org.apache.lucene.analysis.ja.dict.TestToStringUtilSokuon.testSokuonBeforeVoicedConsonant(TestToStringUtilSokuon.java:25)

• The contract. Both overloads say "Romanize katakana with modified hepburn" (ToStringUtil.java:240, :251). Hepburn writes the sokuon by doubling the consonant that follows (tch for ch), with no exception for voiced consonants (the Hepburn page that TestToStringUtil.java:36 points to).
• The method applies the rule itself for four rows (rokku, zasshi, kitto and matchi, kippu); the other rows get no handling at all, the inner switch just falls through.
• Lucene's own later romaji table doubles them. The completion filter's romaji_map.txt ("covers romanization systems: modified Hepburn-shiki, Kunrei-shiki (Nihon-shiki), and Wāpuro shiki", line 3) has ッグ,ggu (:178), ッジ,zzi,jji (:193), ッズ,zzu (:194), ッド,ddo (:212), ッハ,hha (:216), ッフ,hhu,ffu (:218), ッバ,bba (:224), ッブ,bbu (:226). It is supporting precedent, not an oracle for this method: lines 4-5 say the table "does not strictly comply with the romanization systems listed above" and covers input-method keystrokes, and some rows differ from what fix B writes (ッヂ,ddi at :209, where fix B gives jji because this method romanizes ヂ as ji).
• "Used only for debugging" is stale. The class javadoc says so (ToStringUtil.java:24), but the TODO in the same method says "now that this is used by readingsfilter and not just for debugging" (:252-253), and in #5499 (LUCENE-4433, メ romanized as mi) a committer wrote "Now its used by at least a tokenfilter"; that table error was fixed as a bug in 2012.
• Nothing pins the current output. No upstream test has a ッ input (TestToStringUtil, TestJapaneseReadingFormFilter), and no comment, CHANGES or MIGRATE entry mentions the sokuon.
• Precedent. Romaji output defects of this filter were filed under "Bug Fixes": GITHUB#12885 (OOV hiragana, 9.10.0) and SOLR-3906 (OOV half-width kana).

The strongest case for "intended" (the independent reproducer, the intended-behaviour checker and the cross-model lenses rate it moderate): the romanizer is approximate on purpose. It drops the long-vowel mark (マージャン → majan, ロバート → robato, both asserted by upstream tests), so ビール and ビル already share a term; TestToStringUtil says its Hepburn table "isnt even thorough or really probably what we want!"; native and Sino-Japanese words double only k, s, t and p, which may be why only those rows exist; and romaji mode is opt-in.

Why it fails: the approximations cited here are explicit code (case 'ー': break;, ン written m before b/p/m) with tests, while this is an unhandled fall-through with no comment or test; the output is inconsistent (kitto but bagu), so it is not a deliberate "ignore doubling" search key; the native-word pattern explains why the cases were missed, not that dropping was chosen, since the dictionary's readings of common loanwords contain exactly these sequences; and Lucene's own completion table doubles these rows. What remains is a labelling question (bug fix or improvement), not intent. Verdict: not intended, a missing-cases defect.

Both options change only the case 'ッ' block, and neither changes the output of any string without ッ (differential over all 761,943 katakana strings of length 1-3: fix B changes 4,758 outputs, fix A 9,984, every one containing ッ). For a ッ directly before a kana of the g, z/j, d, b or h/f rows or ヴ they agree. They differ in 5,252 strings. In 5,226 of them fix B keeps today's output while fix A also doubles before kana that romanize to n, m, y, r or w, before ヷ-ヺ (ッヷ vva), ン, a second ッ or ー (ッナ nna, ッン nn, ッッカ kkka, ッーカ kka). In the other 26, a double ッ before a row that fix B adds (ッッガ), both change today's output and still differ: stock ga, fix B gga, fix A ggga.

In the style of the existing k/s/t/p cases: the ガ row appends g; ザ, ズ, ゼ, ゾ and ヅ (zu) append z; ジ and ヂ (both ji) append j; ダ, デ and ド append d; the バ row appends b; ハ, ヒ, ヘ and ホ append h; フ (fu) appends f; ヴ appends v. Result: バッグ baggu, ベッド beddo, ビッグ biggu, キッズ kizzu, グッズ guzzu, ブリッジ burijji, スタッフ sutaffu, バッハ bahha, ホッブズ hobbuzu; the k/s/t/p results are unchanged.

            case 'ガ':
            case 'ギ':
            case 'グ':
            case 'ゲ':
            case 'ゴ':
              builder.append('g');
              break main;
            case 'ザ':
            case 'ズ':
            case 'ゼ':
            case 'ゾ':
            case 'ヅ':
              builder.append('z');
              break main;
            case 'ジ':
            case 'ヂ':
              builder.append('j');
              break main;
            case 'ダ':
            case 'デ':
            case 'ド':
              builder.append('d');
              break main;
            case 'バ':
            case 'ビ':
            case 'ブ':
            case 'ベ':
            case 'ボ':
              builder.append('b');
              break main;
            case 'ハ':
            case 'ヒ':
            case 'ヘ':
            case 'ホ':
              builder.append('h');
              break main;
            case 'フ':
              builder.append('f');
              break main;
            case 'ヴ':
              builder.append('v');
              break main;

Trade-offs

• Explicit and allocation-free, and it touches only rows that occur in loanwords.
• It leaves the rare n, m, y, r, w rows and ヷ-ヺ as today: the ッ still vanishes there (these sequences are phonotactically rare, and the checks advised against claiming them).
• Changes indexed romaji terms of these words: existing romaji fields need reindexing.

What the checks validated

• Whole :lucene:analysis:kuromoji:test task plus the paste-ready test, gradle, seed DEADBEEF, scratch worktree at a9779ef3c193: assertions on: 31 classes, 198 tests, 0 failures, 0 errors, 7 skipped; assertions off: 31 classes, 198 tests, 0 failures, 0 errors, 7 skipped. The 7 skips are pre-existing module tests (TestExtendedMode 1, TestFactories 1, TestJapaneseNumberFilter 2, TestJapaneseTokenizer 3); the run includes TestToStringUtil (3), TestJapaneseReadingFormFilter (8, with testRandomData) and TestJapaneseReadingFormFilterFactory (2).
• ecjLintMain, ecjLintTest and checkGoogleJavaFormat of the module with fix B and the test: pass.
• Earlier, in the hunt: the finder's JUnit passes with this variant shadowed in.

In case 'ッ', romanize the next up to 3 characters into a scratch StringBuilder and append its first letter if it is a consonant (t before ch). It replaces the four existing rows (+11/-28) and gives the same k/s/t/p results.

          // the sokuon doubles the first consonant of the following syllable (ch becomes tch)
          if (i < len - 1) {
            StringBuilder next = new StringBuilder();
            getRomanization(next, s.subSequence(i + 1, Math.min(len, i + 4)));
            if (next.length() > 1 && next.charAt(0) == 'c' && next.charAt(1) == 'h') {
              builder.append('t');
            } else if (next.length() > 0
                && next.charAt(0) >= 'a'
                && next.charAt(0) <= 'z'
                && "aiueo".indexOf(next.charAt(0)) < 0) {
              builder.append(next.charAt(0));
            }
          }

Trade-offs

• With less code, covers every following sequence whose romanization starts with an ASCII consonant, including the rare n/m/y/r/w rows; for a trailing ッ, ッー and ッ before the unconverted small ヵ/ヶ it still writes nothing for the ッ.
• Allocates one StringBuilder and recurses on up to 3 characters per ッ: at 4M characters the security screen measured about 101 ns per character on all-ッ input versus 3.9 stock, and 51 versus 10.7 on alternating ッグ input (assertions on, best of 3 on a shared host; the numbers are noisy, and there was no superlinear growth up to 4M characters).
• Its extra outputs are debatable: ッッカ becomes kkka, ッーカ becomes kka. It also doubles non-katakana text after a ッ in a direct call (ッb → bb; stock and fix B b), which the katakana-only differential does not cover.
• Changes indexed romaji terms too.

What the checks validated

• Whole :lucene:analysis:kuromoji:test task plus the paste-ready test, gradle, assertions on: 31 classes, 198 tests, 0 failures, 0 errors, 7 skipped.
• ecjLintMain, ecjLintTest and checkGoogleJavaFormat of the module with fix A and the test: pass.
• Earlier, in the hunt and the registration check: the finder's JUnit, the independent reproduction's JUnits (6/6, assertions off) and the 11 upstream TestToStringUtil + TestJapaneseReadingFormFilter tests pass with it shadowed in; the finder's exhaustive check then reports no sokuon mismatch except ッヵ/ッヶ (the separate small ヵ/ヶ pass-through).

• Unit. A hunt unit that checked kuromoji and nori token filters against their javadoc, with a bounded-exhaustive harness over the stock kuromoji jar.
• Section C of the harness. All 761,943 strings of length 1-3 over U+30A1..U+30FA plus ー were romanized twice (determinism: 0 mismatches) and checked for romaji-only output; then, for every one- or two-kana syllable, ッ + syllable was checked against "double the syllable's first consonant, ch → tch". 145 of 200 consonant-initial syllables lost the ッ. That count includes rare sequences (ッ before n, m, r, y, w), so it is not the headline.
• End to end. The realistic subset, loanwords with ッ before g, z/j, d, b and h/f, was then reproduced through JapaneseTokenizer + JapaneseReadingFormFilter(useRomaji=true) with a public-API JUnit, and checked on releases back to 3.6.0 with a version-independent probe.