> A couple of comments:

Thank you for the thorough reading! (No pun intended :-)

> 1) What is meant by "well-formed S-expression"?

Something that can be read back in.

> What is a "binary S-expression"?

For example this repo <https://github.com/lispunion/database-subprocess>
uses them to talk between Scheme and a SQLite subprocess written in C.

Rivest's proposal https://datatracker.ietf.org/doc/draft-rivest-sexp/
could be construed as binary.

There are probably others.

> 2) Read/write are typically used to exchange data (in a textual
> format). This SRFI does not provide a way to exchange unreadable
> objects between different implementations.

The new draft is explicitly silent on lexical syntax since that proved
controversial. Two implementations supporting the same lexical syntax
for unreadable objects can exchange data.

> 3) The SRFI is probably incompatible to R6RS because R6RS's
> read/get-datum must raise a lexical error as soon as an invalid
> character is encountered while datum syntax is read.

That's only in #!r6rs mode?

In any case, the SRFI should probably say that new &unreadable condition
type is a subtype of the standard &lexical type.

> 4) How are cycles/shared data structures going through unreadable
> objects handled?

Depends entirely on the implementation.

Generally it makes sense for implementations to choose a syntax that is
similar to the standard list syntax and can contain nested objects.
(It's simpler to permit arbitrary nested objects than to come up with
special rules forbidding some of them.) In this case, the nested objects
can be cylic and be dealt with the same way as ordinary lists containing
cyclic structures as elements.

For example, in the sample implementation for STklos:

stklos> #[#1=(1 2 . #1#)]
**** Error:
%read: unreadable: `#[#0=[1 2 . #0#]]'

> 5) The R6RS conditions defined in the SRFI don't have a place in the
> condition hierarchy yet.

 From the sample implementation for "laesare":

(define-condition-type &unreadable &lexical
   make-unreadable-error
   unreadable-error?
   (object unreadable-error-object))

> 6) The usefulness of the SRFI is not yet clear to me.

This is a frequent complaint about SRFIs in general. I'm not sure I can
make the rationale clearer than it is without unduly expanding it.