I did not plan to support dbm hash database. Nor do I planned to support things like cassandra or hbase but that is another topic I guess.
If we can provide a smooth upgrade path for dbm then I agree that it would be a good thing.
I think that persistent (in the on-disk sense, not the functional sense) hash tables, transactional or not, would be more suitable as a separate SRFI. Trying to wedge them into this one is probably not useful.
Question: Should it be explicit in the specification that the library offers such a upgrade path?
I think not.
It seems to me there is no existing library in r7rs that return a procedure.
I don't know if it intentional or the case did not present itself.
The relatively new procedures make-promise and make-parameter do, and of course call/cc passes a new procedure to its argument. There will probably be more such procedures in R7RS-large. There is certainly no objection to them.
Since dbm, would need to do a full "table scan" anyway to emulate those procedure
it does no harm. Also, since there is no transactions, the generator does not make sense,
because it would require to do generator->list then list->generator to be able to produce
the generator.
I think it makes sense. Dbm-type databases typically have firstkey and nextkey operations, which are perfectly suited to stateful generators.