> [ The troika of John, Lassi and Harold excise sync-file (born broken,
>    and still so on Linux) and sync-file-system (badly named, sort of
>    broken by design but traditional, and broken in implementation. ]

:D

> Depend on subject domain experts like the SQLite team and their whole
> software stack when you need the best guarantees available today.

This is a very good point. For general purpose computing, the popular
database vendors have the most incentive to do a good job of this.

> along with notes about system configuration details and trade-offs.

An even better point. There are basically two principled approaches:

1) Be content with the 30-second auto-sync like everyone else.

2) Carefully select and configure your whole hardware, firmware, OS,
database, language and application stack so that every level of the
stack reliably delivers the sync guarantees you need.

Everything in between is voodoo to some degree :)

> Potentially develop a Transaction Manager SRFI that breaks absolutely
> no ground in low level implementation details, concept, and primitives
> and code we ... borrow from the best.  But is easy to grok and use.

This sounds a bit like "fast, safe, easy - pick any two". But major
bragging rights to anyone who manages to pull it off for any scenario.

> This has been a interest of mine since I was given a job to make a
> custom database that just stored data reliable; I'll put it on my
> long term TODO list, during/after tackling the SQL RDBMS issue.

Not the easiest job in the world for one person (or even a team!)