Observed-Remove Set CRDT

删除元素名“x”没有说明删的是哪一次加入。OR-Set 把每次加入看成一张独立票据，remove 只能撕掉手中已经见过的票据。分区另一侧新开的票据不可能被当前 remove 预知，因此保留。

这个规则把并发冲突变成可检查的因果问题，而不是依赖消息到达顺序。所有副本最终拿到相同 add dots 和 remove tag sets 后，无论并发消息怎样穿插，live pair 集都相同。

Dot 不应被复用。若 actor 重启后再次产生 $(A,7)$，旧 remove 针对的票据和新 add 无法区分，新添加可能被过去的删除吞掉。持久 counter 或新 incarnation ID 是数据语义的一部分。

A 添加 $x$，生成

B 收到它后执行 remove，冻结 $T_x=\{a_1\}$。与此同时，尚未见该 remove 的 C 并发执行 $\mathrm{add}(x,c_1)$。全体最终执行三个 effectors 后，状态为

所以 $x$ 存在。无论 C 的 add 在 B 的 remove 前还是后到达，$c_1\notin T_x$，结果不变。

若 C 先观察 B 的 remove，再添加 $x$，新 add 因果后继于 remove，同样产生新 dot 并使 $x$ 再次存在；这是用户重新添加，不是并发冲突。若 B 的 remove prepare 在尚未看到任何 x 时运行，$T_x=\varnothing$，它不会删除将来或并发的任何 add。

朴素 two-phase set 用 add-set 减 remove-set 且按元素名永久禁用重加，语义不同；朴素 LWW-set 又按 marker 选赢家。它们都不能只换名字叫 OR-Set。过早丢掉 remove 的去重或稳定性证据，还会让离线副本重传 $a_1$ 后复活 x。

OR-Set 适合成员标签、购物车和协作选择，其中并发 add 应优先。若业务需要 remove-wins，应让并发 remove 能覆盖未观察 add，必须使用不同因果机制和证明，不能把 $T_e$ 扩成“所有未来 tags”这种不可实现集合。Remove 多个元素时应冻结每个元素各自的 observed dots；只广播元素名会丢失同一 API 调用的因果边界。

状态型优化可把 live dots 与 causal context 合并，避免为每个删除永久保留显式 tombstone；其 merge 仍要区分“对方没见 dot”和“对方已见并删除 dot”。本页的 op-based 定义则把这一区分冻结在 remove effector 与交付合同中。