OK some more. This time I really do read it :)

add1 is used in examples but not really defined. Common sense probably
works. But for specifications like these I think it's better to avoid
that. In some other examples like 'rany', "add1" is basically spelled
out as a lambda instead, which works too.

For rany part, the second example returns "5" on Guile, Chibi and
Gauche, not #t. Perhaps it's the problem with 'rany' implementation?
Or perhaps this function could be described in more detail if "5" is
expected.

Maybe I suggest rename delete-neighbor-dupes with tunique? It seems to
do the same thing UNIX "uniq" (or C++ std::unique) does. The name is a
bit shorter but does not really lose any meaning.

Which makes me think if we should have tsort, since the equivalent of
tdelete-duplicates in UNIX/C++ is basically "sort | uniq". Then we
don't need tdelete-duplicates because you can easily compose. I guess
not because most sort algorithm needs to read the whole (or a big
chunk) of the input to do its job, except merge sort...

The stateful transducers do make me wonder if we could avoid mutation
by making the transducer return the result _and_ a (optionally new)
transducer though. That way the state could be carried along with the
new transducer, kinda like fold. The overhead is likely higher than
stateful implementation.

That's it! Nice SRFI.
--
Duy