Here are some comments, mostly very minor, on draft 4 (2016-04-12) of
SRFI 130.  Caveat: I am not completely caught up on previous messages on
the list, so please excuse any mention of items that were resolved
there.

  * Para just before Procedures section: typo "vlue"

  * string-cursor-diff: Is there a significance to the use of the
    phrase "between cursor2 and cursor1" instead of "between cursor1
    and cursor2"?  Also, is it correct that if the arguments are
    cursors then the result is always nonnegative but if the arguments
    are indexes then the result may be negative?  If so, what is the
    motivation for this difference?

  * string-every (and string-any): In the last para, the phrase "in
    the predicate case" seems like a holdover from an earlier version
    where pred could be a character(-set).  (I realize that is still
    permitted as an implementation extension, based on the
    introduction.)

  * string-tabulate: The order of the arguments is reversed from the
    order used by SRFI-1's list-tabulate.  Is it intentional?  If so,
    it may be useful to alert the reader to the difference here.

  * (minor) The discussion starting with "Interested functional
    programmers" could be moved to after the description of
    string-fold-right in order to avoid a forward reference.

  * string-unfold-right: I believe "equivalent to string-fold" should
    read "equivalent to string-unfold".

  * string->vector/cursors: Shouldn't the signature "char-list ->
    string" read "s [start end] -> vector"?  (The latter matches the
    sample implementation.)  Also, the note about 'substring' seems
    out of place here.  Does it refer to the difference between
    substring/cursors and R7RS's substring?

  * The sample implementation does not seem to define
    string-ref/cursor.

  * (minor) substring/cursors: "procedures returns" should read
    "procedures return" or "procedures each return".  The distinction
    between substring/cursors and string-copy/cursors may be clearer
    if there were a reminder here that string-copy/cursors may return
    a string that shares storage with s.  (It is certainly mentioned
    earlier, in the Shared storage section, but it is easy to miss,
    especially if someone is looking up only a few procedures, and
    also because the two similarly-named procedures in R7RS are
    synonyms.)

  * string-take etc.: Is it true that if the result is the entire
    string s, then an implementation may return either s or a copy of
    s, but not a copy that shares storage with s (assuming there is
    such a thing)?  Mostly, I'm trying to understand the significance
    of distinguishing the case in which the entire string is returned
    from one that returns a proper substring, which the description
    mentions separately (here and in a few other places).

  * (minor) string-index etc.: It may be helpful to include a
    symmetric comment "If no match is found..." for
    string-index-right.  I assume the return value will be start in
    this case.

  * (minor) string-contains: Should the example include
    string-cursor->index to be sure to yield 15 for arbitrary cursor
    implementations?

  * (minor) string-concatenate-reverse: missing space after
    'substring' in example.

  * string-for-each-cursor: The example seems to be missing a
    string-ref and includes an unused len.  Something like the
    following could be used:

      (string-for-each-cursor (lambda (i)
     	                          (write-char (string-ref s i)))
      										    s)

  * string-replicate: Is it an error if from > to?  (This may have
    been noted somewhere earlier, but I couldn't find it quickly and a
    reminder here may be good nonetheless.)

  * string-replace: [I just read May 9th message from Alex Shinn that
    notes the problem and fix].

  * (minor) string-split: "Delimiter specifies a string whose
    characters are to be used as the word separator" could be
    interpreted to mean that each character in the delimiter string is
    treated as a separator (as a character-set).  The next sentence
    does clarify the issue.  However, perhaps replacing "whose
    characters are" with "that is" would be clearer.

  * (minor) string-split: A pointer to SRFI-115's regexp-split (or a
	  reminder to use string-split only for simple tasks) may be a good
	  addition to the description of string-split.  I found myself
	  wondering about why delimiter was limited to a string until I read
	  some comments on the mailing list.  (SRFI-13's description of
	  string-tokenize provides some text along similar lines, I think.)

Regards,

-chaw