仓颉在非qwerty布局使用xlit转换输入码

[phoulx]

目前在用Colemak和仓颉，由于布局不同导致非输入状态时快捷键经常按错，所以考虑将仓颉的布局改为和Colemak一致。
又因为内置的仓颉dict是基于qwerty映射的，想到最方便的方法是输入时按键先经过转换（colemak -> qwerty）再查dict。
经过搜索也看到了这样的用法：#898、#999。
但当我如下修改cangjie5.schema.yaml时：

speller:
  alphabet: zyxwvutsrqponmlkjihgfedcba;
  delimiter: " ;" // 未改动
  algebra:
    - "xlit|abcdefghijklmnopqrstuvwxyz;|abcsftdhuneimky;qprglvwxjzo|"

倒是可以用改过的键位打出字，但井非期望那样替换原键位，而是一个键现在变成对应两个仓颉码。
如S键（对应qwerty的D键位置，qwerty仓颉的「木」码），原先按S键会打出「尸」（qwerty仓颉S键对应码），期望修改後打出「木」。但实际上修改後「尸」和「木」会同时出现在候选列表，并且「尸」的优先级更高。如下图：

输入多个键时问题同。
尝试同时修改translator/comment_format和translator/preedit_format的字串，对问题没有影响。
环境：

Debian Sid, ibus-rime 1.5.0, librime 1.10.0

也在macOS尝试了，问题表现相同：

macOS 14.3, Squirrel 0.16.1, librime 1.8.5

所以应与平台无关。
不确定这是xlit转换的特性还是有什么bug，盼解答～

当然还有一种方法是修改码表，但毕竟修改并维护一份码表比改几行配置要麻烦很多，而且我也不需要诸如造词等功能，所以希望尽量从配置这里解决。

[gaboolic]

如果想判断是不是xlit的问题，可以使用xform 先改一个s 试试

如果xform没问题，那就是xlit的问题
理论上xlit没问题，从你的现象看上去 似乎是derive

[phoulx]

使用xform改也是出两个码

[CHANTXU64]

直接改码表，简单无bug。写个脚本维护就行，见 https://github.com/CHANTXU64/simple-huma-dvorak ，tools下的js脚本，然后运行build.sh就行

[phoulx]

嗯最後是改了码表（python脚本），确实简单直接