> This entire idea was a non-starter, in my view.

The alternatives were to withdraw it or make the best of it.

I like the result, but it's clearly more in the "basic research / long
term evolution" category than something that's useful today. RnRS should
address concerns like this though.

Basically this solves a longstanding inconsistency in the `write`
procedure. `write` wrote a self-consistent data structure in all cases
except when it's fed unreadable objects. An implementation using
stand-in objects can guarantee self-consistent output in all cases.

(The same inelegance exists in Common Lisp and the same solution could
be applied.)

Interestingly, Clojure seems to have addressed the problem:

user=> +
#object[clojure.core$_PLUS_ 0x2f40a43 "clojure.core$xxxxxx@2f40a43"]

user=> #object[clojure.core$_PLUS_ 0x2f40a43 "clojure.core$xxxxxx@2f40a43"]
Syntax error reading source at (REPL:11:69).
No reader function for tag object

>> 6) The usefulness of the SRFI is not yet clear to me.
> Me neither. I continue to lean towards withdrawal as the best option, although I think a cut down version/hybrid of this version and the original could be useful, if it standardized all of:
> 1. #< being a sequence which signals an error when read, probably with no recovery mechanism, though I kind of like the idea of ‘stand-in objects’

The stand-in objects are the reason I didn't withdraw the SRFI.

I'm against mixing lexical syntax and procedures in the same SRFI. In my
opinion, that causes predictable problems which are avoided by putting
syntax in a separate SRFI. The main problem is that lexical syntax is
much more contentious than mere procedures. Ways to "library-ize"
lexical syntax are also contentious and underdeveloped.

> 2. unreadable-object? as a predicate when called on an object which would be unreadable (i.e. generate a #<) if it were fed to write

In the current SRFI, "unreadable-object?" means something different,
namely it tests for the particular data type used to wrap stand-ins.

An "unwritable-object?" might be useful but it's not clear how easy it
is for existing implementations to add.

(Per the current SRFI, you first need to try to write an object, and if
that fails, you get back an exception satisfying "unwritable-error?")

> 3. the R6RS errors with appropriate places in the condition hierarchy

This is covered by the current SRFI, if we specify that &unreadable is a
subtype of &lexical as it is in the sample implementation.