- The way deleted data is encoded in yjs is awkward. Versions store a list of which content has been deleted. So versions are bigger than they need to be, and you can't replay the editing history without stored snapshots. I think the knowledge of which elements have been deleted should just be saved into the binary format alongside the inserts.

- For javascript objects, yjs pretends each value is actually a list (with everything after the first element ignored) so it can reuse the logic for list editing. This is overcomplicated compared to Shelf or something like it.

- Yjs's internal structure is a linked list with cached offsets. This works ok in practice because inserts usually appear close to each other, but it means yjs has O(n^2) performance to process n edits rather than O(n log n). Diamond types (via wasm) is about 30x faster as a result - though as you say, yjs is still plenty fast enough in practice for most applications. And this gap will narrow once Yrs is working well.

- Yjs can have an interleaving problem when concurrent items are prepended at the same location in a list.

- The current (new) diamond types file format stores the origin-position + parents information instead of storing left-origin / right-origin fields. This lets DT have a smaller file size while storing more information than yjs stores. And I think this format is easier for applications to encode and work with, and it will make pruning easier when we get to it. We should also be able to load & save faster than yjs - but I'm not benchmarking that yet.

But all of this stuff is pretty minor. Yjs works well in practice, and its quite mature. Performance will only get better with the yrs rust implementation. For diamond types, I had the benefit of being able to copy some fantastic implementation ideas from Yjs. If diamond types is better than yjs, its because I'm standing on its shoulders.