Characters in U+3000 to U+30FF make WinCompose send stale characters to certain applications

[iBug]

This is a very strange issue that I could not understand.

Reproduction steps

1. Add the following custom sequence to .XCompose and reload:

   <Multi_key> <bracketright> <bracketright> : "」"
   <Multi_key> <bracketleft> <bracketleft> : "「"
   

2. Open Telegram Desktop and open a chat

3. Hit Compose [ [ and see 「 pops up

4. Hit Compose ] ] and see another 「 pops up (Wrong!, expected 」)

5. Hit Compose [ ] and see another 「 pops up (also wrong, expected ⬚ - this is a built-in sequence)

6. Hit Compose ] ] again and see 」 pops up (correct, see notes below)

Notes

The triggering criteria appears to depend on a number of factors:

• Only characters between U+3000 and U+30FF (inclusive) are affected. For example, if I hit Compose [ ] = ⬚ after step 3, then step 4 produces the desired 」 character.

  If more affected characters are added to .XCompose, then this issue extends. For example:

  <Multi_key> <z> <z> : "【"
  <Multi_key> <x> <x> : "】"
  <Multi_key> <z> <x> : "『"
  <Multi_key> <x> <z> : "』"
  

  7. If I hit Compose z z after step 4, another 「 comes up.
  8. If I hit Compose z x after step 7, another 「 comes up.
  9. (Repeats indefinitely)

  I tested multiple characters from U+3000 to U+30FF and they appear to be all affected. Notably, this includes both U+3000 and U+30FF themselves. The adjacent valid code points around this range, namely U+2FFB and U+3105, are not affected, however, and behave as "remedies" as described in the next bullet point.

• Characters outside the affected range act as "remedies". The Debug Window shows that WinCompose attempted to produce the correct character, but somehow ended up with the old one.

  

  While step 5 also produced the same "stale" character, it appears like it cleared an internal buffer that allowed step 6 to produce the correct character.

  Replace step 5 with another custom sequence also "clears this internal buffer". I have tested half-width characters, emojis, and Chinese characters and they all work, e.g. <Multi_key> <q> <q> : "好".

• Only triggers on Qt applications. Incompatibilities with Qt applications — characters getting stuck in memory #63 is possibly related, but I can consistently reproduce this issue after restarting WinCompose with or without Administrator privileges. Telegram Desktop is always started as normal user (w/o Admin privs).

  I could not reproduce this bug on Notepad, Microsoft Edge or VS Code. I don't have any other Qt application to test with, either, so Telegram Desktop is the only app that exhibits this behavior.

• The input sequence is non-influential. Changing the sequence to use multiple Compose keys does not change the behavior of the characters.