I think it's your job as a designer to encode which update should win. In case of equivalent updates like writing to a field they suggest 'last update wins" strategy.
For words, if a word is a single unit in your system, delete obviously beats amendment.
This only works for very simple cases where there is already an existing strategy, but I have yet to see strategies for more complicated cases, especially ones where you also need to preserve some kind of consistency. Ultimately this boils down to "write your own CRDT", where CRDT is no longer a tool but just a definition to satisfy.
> suggest 'last update wins" strategy.
Hmm, last update as it's received by a central server? Last update according to the time on the device doing committing the update? The rabbit hole just keeps going, for each decision you get multiple new edge cases with unintended behavior...
CRDTs mostly have a time notions like Lamport clocks, vector clocks, ... not actual device time => see more here: https://adamwulf.me/2021/05/distributed-clocks-and-crdts/
All of which have their own weaknesses. And all of them can suffer the split brain scenario.
And all but the last one fundamentally have lots of edge cases with e.g. high-latency sync
CRDTs are not a solved problem as of today, there is no perfect solution in the current state-of-the-art, it's still a field with quite some active research.
It's most likely causality-based time, not the time per an atomic clock.
Sounds like a job for a block chain!