Just closing the loop on your responses.  Thank you for combing
through my questions.

> >  If 'transaction' is a handle to a currently running transaction why is the predicate called okvs-transaction?  I'd expect the type to be called okvs-transaction.
> Well, that should be fixed too. Predicate will be okvs-transaction? and record-type will be <okvs-transaction>. Is that ok?

Yes.

>> 6) What precisely are the semantics of the hash-table returned from okvs-transaction-metadata?  Does this documentation need to refer to a particular RnRs or other SRFI?
> Yes, it is a mistake. The hashtable is a R7RS hashtable. Thanks.
>> What happens if I mutate it? :)
> FWIW, it is at the start empty and is intended to be mutated.  I use in fstore to keep track of whether the transaction is "dirty" or not. In this context, a transaction is dirty if it has mutated the store.

It's not clear to me how it is intended to be mutated by the user.
It's not clear to me how mutating it impacts other parts of the SRFI.

>> 8) Could okvs-debug simply be made a degenerate case of okvs-range?
> We briefly discussed that. The idea behind okvs-debug, is that you can use
> it anywhere without transaction ceremony, that is a debug procedure.
> ...
> I am not in favour of removing okvs-debug.

The behavior of a debugging procedure will be unique to the
implementation.  For example, how do in-flight transactions appear in
the debugging output?  It doesn't seem worth standardizing such an
underspecified operation (though no harm in leaving it in the
reference implementation).

>> 9) What does it mean for the 'home' in (okvs home) to be an address?
> It is implementation dependant. I guess, It is most likely a string.
Maybe use a less overloaded token?  Address sounds like a network
endpoint of some sort.

>> 13) Is start-key/start-include/end-key/end-include some best practice from elsewhere?  How far can you go in simplifying the API with a half-open interval [start, end) where end is implied to be okvs-maximum-key when omitted?
> okvs-maximum-key is staged for removal, it seems you prefer to keep it.

No complaints if it is to be removed.

> Like (briefly) discussed in this thread, there seem to be no good reason
> to do an half-open interval.
>
> If what you want is to retrieve all values of a given "space" the space
> must be anyway prefixed with a particular "value" to be able to tell which
> keys are from the space you are interested in.

A "space" prefix is nothing but the half-open interval [prefix, prefix
+ 1).  The half-open interval provides space semantics for free, no?

>> 15) Why don't all the procedures returning an SRFI-158 generator have some common token in the name?  Some are called 'range' while okvs-prefix omits it.
> I am not sure I understand the question correctly.
Sorry to be unclear.  If there are a bunch of procedures returning
generators, I would expect them to have similar names.  There are
naming consistencies.  For example, if okvs-prefix returns a generator
why not have it include 'range' in the name?

> I hope I answered all the questions correctly.
Absolutely!  Thank you for your hard work here.

- Rhys