> Beside this, the description of `make-queue-with-list` seems forcing
> implementations to use a list as its storage. I think this is a bit
> over specifying.


I am apprehensive about specifying a SRFI such that only one underlying data structure may be used. SRFI 69 is loose enough that any of the major hash table variants could be used to implement it, which I think is a good thing. In the long run, constant factors change, so it is beneficial to be able to swap out implementations.

An efficient FIFO queue can be implemented not only with a singly-linked list with back pointer, but also with a doubly-circularly linked list, self-resizing vector, two stacks, or a finger tree. An implementor might have a legitimate reason for preferring one of these alternatives. For instance, a size-conscious implementation like Chibi might prefer to reuse an existing structure instead of implementing a new one.
I'm perfectly
willing to rename the SRFI itself, but I'd like input on how to rename
the procedures, if at all.  If they keep "queue", it may be confusing
if there is another queue SRFI (there will be, as I mentioned, a SRFI
from Kevin Wortman that includes deques based on finger trees).

This sounds like a good compromisze, changing SRFI 117's name slightly to make its implementation-specificity explicit.

Kevin Wortman