That's pretty restricting in how you use this SRFI, and will encourage frequent opening and closing the database, which might be expensive in some naive server based implementations, but for those will encourage connection pooling.  It will also encourage making config global state, instead of using it once in a single call to okvs-open.

I think it's less necessary than doing this for transactions, which have a much shorter lexical existence, in part because exiting the program should do an implicit okvs-close, at least upon the next opening of the database.  All OKVSes that are worth using had better do something sane when a program exits without a formal close....  For that matter, ones that don't provide a server but are just library code probably don't really require a formal close as long as there's no transaction in progress.

Well, maybe; for example, MongoDB's default configuration for WiredTiger does a checkpoint every 60 seconds instead of on every transaction commit, and originally would do a checkpoint if 2 MiB or 2 GiB had been written before 60 seconds had elapsed.  And as previously discussed, "Snapchat for databases" is a valid model for a variety of use cases, as long as this sort of thing doesn't result in corrupting the database.

So ... I'm now unconvinced my point is correct or the best option.

Fewer arguments to okvs-open or with-okvs sounds superior to me, although as you note, and I'll go further, anything persistent with today's operating systems is going to need something to say where the backing storage is located.  It could be made a required config parameter, thus making config required.

- Harold