Agreed that any unrecognized CONFIG options should signal an error, that's very possibly a sign you're using a database different than the one you think you're using.  Plus it's natural and nicely simplifying to include 'home in them if needed.

okvs-debug has been removed as discussed, but the description for okvs-from should include a note with the example you mention in the commit, adding a bit to include the database's maximum key, since iterating across all keys will be desired.  And that suggests we should bring back the procedure that returns you the maximum key, although I forget the arguments for why it shouldn't be in the SRFI.

What okvs-transaction-state returns and what you can do with it are still obscure.

The use of "SOME"/"some" in commit 2fe1c762a0940da8fea7f848b0e6df6caae7adec is ... inelegant.  Although anything there, including spelling out "okvs or transaction object", needs an explanation.  John's excellent suggestion of 'auto-commit doesn't get around the fact that the procedures need some sort of reference to the database somewhere in their args, I agree that one overloaded argument is fine, and my suggestion of setting the value of a quoted atom to the database is truly inelegant.

Maybe (something)-REFERENCE?  (something)-OR-TRANSACTION-HANDLE?

Repeating the same explanation of "some" 6 times is not good, it should be explained once before its first use, after okvs-open and the procedure(s) that create a transaction handle.

Otherwise looks very good.

- Harold