> IMO, that is not a good idea, to put it mildly.  Since these
> properties can potentially span very few characters, or even change
> the value at each buffer position in extreme cases, they will most
> probably slow down redisplay, perhaps even significantly so.  The
> problem here is that the display engine always knows where's the next
> buffer position, called "stop position" at which text properties
> change values.  Between the stop positions, the display engine runs at
> full throttle, using the information about properties (notably, faces)
> and overlays it computed at the last stop position.  But when it comes
> to the next stop position, it stops and reconsiders all the stuff that
> can affect display: text properties (faces, invisibility), overlays,
> composed characters, etc., something that requires non-trivial
> processing.  Having text properties change too often will cause
> slowdown, even though these properties don't affect redisplay.

Thanks for the insight, I’ve never knew Emacs internal so much
to be able to consider this. The optimistic side is that I’m using
the merge-item approach as in Yjs so hopefully text property change
is not so frequent…

> I'm not sure we need to implement this in Emacs.  For example, Tandem
> doesn't require this from its plugins; presumably, it builds the
> character IDs internally?  You could look at its implementation of
> CRDT and take the ideas from there; AFAIU, it requires only a couple
> of very simple operations to be implemented by plugins.

IMO the problem of this approach is that if there’s any desync between
buffer in the library and buffer in the editor the outcome is disastrous,
and this can not only come from some bug — Emacs and C library
has to talk asynchronously and bidirectionally, which means theoretically
there will be case that Emacs does some change, sent a message to
C library, but some message before C library receive the change from
Emacs arrives later 
    Emacs C-Library
 |      |  \   /  |
 |      |    X   |
 |      |  /   \  |
V
Although the latency window on local machine is very small, the latency
of Emacs Lisp interpreter responding to events is a another complication...
There are way to work around this of course, but it’ll definitely require more
work rather than just sending simple operation and buffer position, at least
there need to be UID for each operation and some transaction mechanism.

I see that Tandem send old text and new text with the text operation. This
is definitely a workaround with no correctness guarantee, and it doesn’t
specify what to do when a desync happens. But those are just my mutering
about correctness, I can imagine that it might work good enough in practice.