I haven't scrutinized it thoroughly, but this SRFI looks very nice.
Some of the formatting is a little confusing: the prototypes are not
very clearly distinguished from the other text; perhaps it could be
indented differently, and the word `procedure' could precede the
prototype or be right-justifed:
procedure: (car /pair/)
or
(car /pair/) procedure
Returns the contents of the car field of /pair/.

I agree the formatting could be improved. I will try to address this in
the next revision.

LIST-REF/UPDATE is sometimes overkill -- perhaps an operation just to
modify the element at a particular index would be worth adding, say
(LIST-MODIFY <list> <index> <procedure>), which would return just the
new list with the element E at <index> replaced by (<procedure> E).

I added `list-ref/update', even though `list-ref' and `list-set' are
sufficient. This operation generalizes both ref & set and the
`list-modify' (I would call it list-update) operation you propose. The
reason for this is purely concerns of efficiency. All are implementable
in terms of set & ref in O(log n) total time, but `list-ref/update'
needs to make a single access of the appropriate element in the list.

Since random-access lists are (or at least may be, in general)
incompatible with sequential lists, if you have written code to use
SRFI 101, how do you use rest lists in n-ary procedures, and APPLY,
or, more generally, how do you use code that expects sequential lists?
This will be important to address for anyone to actually use
random-access lists.

Just so there is no confusion: random-access lists are not incompatible
with sequential lists in the sense that one has to commit to use
random-access lists to the exclusions of traditional lists. It is
expected that programs may make use of *both* data types in the same
program (via prefixing of identifiers). They are incompatible in the
sense that they are (potentially) disjoint. So unless a system uses
random-access lists as its core pair type, bad things will happen if you
`apply' a function to a random-access list of arguments, just as will
happen if you `apply' a function to a vector of arguments.

I could add conversion functions if that seems useful (they are trivial
to define in terms of the folds given). In a system that really
embraces the random-access pair type as fundamental, these would just be
identities.

But that brings up the issue I mentioned in another thread. How far
should this library go to make random-access pairs usable in place of
traditional pairs. Should it define a random-access version of `apply'?
How about `quote', etc.? Should it define a `lambda' form that
constructs rest lists as random-access lists? I am beginning to think
yes, but I'd welcome feedback. In any case, I will add this to the list
of issues in the next revision.