1) I suggest exposing the textual->text macro provided in the
implementation, either as a macro or as a wrapper procedure.  It may be
convenient for users that want to make sure they are always getting the
O(1) benefit.

2) I think that the O(mn) constraint on text-contains(-right) should be
flushed, so that implementations that favor either small data or small
code can coexist with those that favor speed.

3) Since text-tabulate is just a special case of text-unfold, its
procedure should be allowed to return a character or textual, as is the
case for the text-unfold mapper procedure.

4) The phrases "character, string, or text" and "string, character,
or text" should be replaced throughout with "character or textual".

5) In R7RS-small and following SRFIs, RFC 2119 mustard is used only
for the implementation, not for the user.  So the use of "must" in in
text-unfold should be replaced by "It is an error unless" or similar
wording.

6) The reference to s2 in textual-replace should be textual2.

7) In textual-split, the phrases "text or string" and "empty text"
should be "textual" and "empty textual" respectively.

8) I think on reflection that textual-count should be flushed and the
remaining fold/map procedures included.  I would flush -filter and -remove
too except that they are useful for low-level whitelisting or blacklisting
of characters.  This satisfies Issue 1.

9) Issues 2 and 3 should be moved to the Rationale section.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
        --The Linux-nationale by Greg Baker