> Это было бы интересное решение, если бы объём для сохранения был небольшим,
> но OD* - файл-контейнер в котором могут храниться и бинарные данные,
> помимо собственно разметки.

Очевидное решение – хранить разметку и бинарные данные отдельно ;).
Но да, придется вводить промежуточный формат.

> Допустим у тебя презентация эдак на 100Мб (не редкость, кстати). Мало, что
> для того, чтобы в процессе сохранения можно было пользоваться редактором, придётся
> всё это держать в буфере такого же размера + придумывать механизм
> как их держать синхронизированными, или держать документ, запретив редактирование.

Все уже придуманно до нас (ц) ;). Есть такая вещь, как кэш:
https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics...
https://lwn.net/Articles/591994/
Т.е. как раз, если не пытаться особо мудрить, то и загружаться в память и писаться на диск будут только обрабатываемые части файла. Тут главное, чтобы не нарушилась консистентность данных при падении во время записи.

Ну или второй процесс-"хранитель", с которым синхронизуемся раз в секунду. Скопировать сотню-другую MB в памяти можно без проблем.

> При такой скорости сброса сохранение будет идти минут 5, за которые юзер
> уже успеет ещё что-то наработать (поудолять десяток слайдов например и добавить
> новых).

Поудалять - вообще не проблема. Добавить -– очень зависит от способа. Можно хранить ссылки, можно в конце-концов плюнуть на этот corner-case, ведь беспроблемное восстановление в других случаях лучще, чем подход "ни вашим, ни нашим".

> И даже, если  как-то исхитриться и реализовать diff-сохранение  (или лог), то проблему вставки/удаления
> это не решает.

Как я уже писал выше, простейший "постраничный" дифф реализован на уровне ОСи,  удаление элементов при правильном подходе тоже дешевая операция и только при вставке на пару десятков-сотен мб может возникнуть "затык". Но опять же, зависит от того, как (откуда) вставляются данные.  Да и ежесекундные вставки такого порядка как-то немного притянуты за уши ;)

> В чём плюсы такого подхода? Я лично не представляю как его реализовать
> так, чтобы он был работоспособным. Охотно поверю, что только я не
> представляю и почитаю (а то и посмотрю) работоспособные варианты реализации.

В документообработчкиках хз, а вот в  ФС или тех же БД требования насчет консистенции и синхронизации данных, как и сами нагрузки ну никак не меньше ;)