idx: 全バリアントを1つのorderに並べ、出力時に取捨して番号を詰める

排他キーも別々の要素として並べる。出力はバリアントを選択した構成を単位とし、
対象外のキーを除いた並びの位置をそのままキー番号にする。同じ配線の排他キーは
選択後に同時には残らないため、番号を共有させる必要がない。
保存したorderは選択で書き換えず、番号の互換性は出力レイアウトごとに扱う。

6d0eba9 で「IDXは番号を共有できる」と書いたが、共有をやめる形に変える。
コミュニティレイアウトの並びを取捨で得られるかは、この方式では未検証のため
IDXのP-1として残す。

Journal: journal/2026-09-22-idx-variant-output.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DKW58HEg8zAQoLrkWByPfD

journal/2026-09-22-idx-variant-output.md

@@ -0,0 +1,38 @@
+# IDXの全体の並びとバリアント選択後の出力番号
+
+## 結論
+
+IDXは全バリアントの対象キーを `order: string[]` に持つ。同じ配線を使う排他キーも別々に並べる。
+出力時に選択した構成のキーだけを残し、残った並びの位置を0から連続する出力番号とする。
+保存したorderは変更しない。公開番号の互換性は出力レイアウトごとに扱う。
+ユーザーがこの方針を採用した。
+
+## 案の比較
+
+| 案 | 扱い |
+| --- | --- |
+| 1つのorderに全キーを置き、出力時に取捨して詰める | 採用 |
+| 同じ配線の排他キーは番号を共有し、選択後も番号を詰めない | 今回置き換えた旧仕様 |
+| レイアウトごとに独立したIDXを保存する | 採用しない |
+
+## 決定理由と例
+
+ユーザーは、ANSIのバックスラッシュとISOの # が同じ配線を使っても、IDXでは別々の位置を持つことを希望した。
+QとAが共通キーなら、全体のorderを `Q, backslash, A, hash` と置くことで、
+ANSIでは `Q, backslash, A`、ISOでは `Q, A, hash` を取捨だけで得られる。
+ISO出力の番号は0, 1, 2であり、保存したorderでの位置0, 2, 3とは区別する。
+
+旧仕様は、全バリアントを含む番号と配線の対応表に同じ接続先が重複することを理由に、番号共有を必須としていた。
+今回の出力単位はバリアント選択済みの構成であり、排他キーは同時に残らないため、その理由は当てはまらない。
+全バリアントを一度に含むキー番号の対応表は、今回の出力方式には含めない。
+
+MAPはPHYキーIDへの割り当てを保持する。出力時に配線の対応表とMAPの配列へ同じ選択後の並びを適用する。
+ELCの保存データは全バリアントの配線を保持し、LEDチェーンも選択によって取捨・詰め直しをしない。
+
+## 未検証の範囲
+
+例での解消は、既存コミュニティレイアウト全般に対応できることの検証ではない。
+従来の実データ調査は、既存のLAYOUT_all等の並びから他の並びを取捨できるかを調べたものだった。
+今回の、別々のPHYキーIDを使って全体のorderを構成する方式については改めて確認が必要。
+共通キー同士の要求順がレイアウト間で逆転する場合には単一のorderで表せない。
+その実例の有無と互換出力の対応範囲を、IDX P-1の残余として残す。