>> I’m not sure if it’s easy (or worth the effort) to provide CRDT in an 
>> editor-agnostic way from C-level. Seems that the most natural
>> choice is to tag characters with CRDT data structures. Emacs has
>> text property which is very suitable for this, and I’m implementing
>> it in this way as an Elisp library. However, this relies on the particular
>> data structure for buffer/text emacs uses.
>> 
>> If implemented as a separate C library, I imagine the CRDT library
>> need to have its own buffer/text data structure and somehow keep
>> in sync with Emacs’ .. doesn’t sound so clean.
> 
> I'm probably missing something because I don't understand the problem
> that worries you.  Given the information about how to update a buffer,
> isn't it relatively easy to generate a series of insert/delete/replace
> operations from that information?  And if so, those actions can be
> almost trivially converted to Emacs primitives that manipulate buffer
> text.  What am I missing?
I was just thinking in general, keeping several copy of data and trying 
to get in sync is a likely source of bug and maintenance problems. 
Suppose there are some bug in the implementation and the CRDT lose
track of some part of the text. If CRDT is attached to Emacs buffer, all
operation will still operate almost correctly and resolve to the
correct intents — because they are item based rather than buffer
position based. Suppose it’s implemented in C library way and C
library communicate to Emacs via buffer position information —
the extra text will make the position off and completely mess up
any further operation on this buffer.

Also this scenario doesn’t necessarily comes from a bug in CRDT
implementation — there’s inhibit-modification-hooks which may
prevent some changes to be told to the C library.

I agree that there’s no problem with C library if everything behaves
well — I don’t like the idea of keeping two replicate of data to keep
in sync (the whole CRDT is to solve this) but it might be my personal
opinion.