我来解释一下 Rime 作者为什么不接受这个实现方式，以及作者期望的可能的实现方式。

按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。

实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。

现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。

作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。

这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。

fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。

具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。

我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。