不知道 org-mode 9.8 pre 对 id 机制进行了怎样的改动，org-supertag 在该版本下疯狂报错，以及我在这个问题上浪费的无数时间。
现在我把 emacs 降级到 29.4，org-supertag 一点事情都没有，非常稳当。
【更新】：仔细回忆之前的报错消息，主要应该是 org-id 保存数据的格式有所变动，之前是纯 alist，但现在 org-id-location-update 增加了直接将 alist 转换到 hash-table 的功能，然后保存到 .org-id-locations 之后，无法被 org-id-locations-load 函数读取，因此报错。
暂时还是回退版本较为安全。
【更新2】在群友的提醒下，我重新升级回 emacs 31，然后再打开文件，org-id 的报错没有再出现…
问题可能和 org-element-cache 有关，即便我把 .org-id-locations 里的记录全部删除， 还是会虚空传进和之前一模一样的记录来。
【更新 3】仔细检查代码，发现了 2 两个重复的更新 id 的语句。删掉就不报错了🤦♂️
大佬要不要考虑适配一种通用的 supertag 的机制，不依赖现有的 major mode。
不知道行不行，当前依赖 org-mode 本身对它自己语法的解析，包括 Headline 的判断，对 Property 的判断。如果是通用的 supertag 机制，不知道要兼容哪些格式。
主要是，如果是脱离 org-mode 话，缺少了以上这些基础的语法解析特性，supertag 会不会只剩下定位这一功能了？
我不确定。你怎么看？
就是自定义一种通用的 property 的格式和解析，只要开启了 supertag 这个minor mode 就可以预定的方式展示、解析和使用命令。这样无论用户选择用 major mode，即使是 txt 文本，都能使用 supertag 的功能。因为有些人可能不用 org-mode，通用化可以满足更普遍的需求。
BTW，这只是我个人的想法，我现在写插件都喜欢写成通用化的 minor mode，这是我的个人偏好，LZ 可以不用在意
我觉得这个讨论方向很有意义。提供了另外的可能性，而且我也有点觉得 org-mode 的技术债有点多。就 org-id 的机制，我都觉得非常得笨重且累赘，希望新的一年，在新的领导人带领下，可以瘦身。
我比较关心实现的可能性，就是摆脱 org-mode 依赖，让它兼容各类格式，而且不受影响。我可能关注点在于，不管什么格式，怎么取值的问题。如果只是 Markdown，倒是简单，如果还要兼容别的语法，估计得折腾。以及我还希望保持一点，就是将一个标题与另外一个标题之间的内容，都视为一整个 node——这个是 org-element 机制做得好的地方，如果我不使用这个机制，我该如何处理。
上面是我的一些简短的想法，你怎么看？