As I am mentioned in the Acknowledgements section for challenging
almost everything in this SRFI, I think it makes sense to speak up,
hoping that my opinion is valuable for the Scheme community.

Every addition to the language has to be benchmarked against the
following principles:

1. Does the addition make the language more expressive?

2. Does the addition simplify solutions to sensible programming problems?

3. Does the addition improve the semantics of the language?

4. Does the addition help the language moving forward?

5. Does the addition play well with existing specifications of the language?

I fail to see how uninterned symbols contribute to any of these points
positively:

1. The existing language already has plenty of other methods to create
objects that are not `eq?` to any existing object. This has already
been observed by John.

2. The only use case given in the SRFI is macro programming (for
communicating between procedures, any other objects besides symbols
can be used). However, the SRFI fails to give an example that can be
critisied. R6RS already has `generate-temporaries', and it would be
enough to make it explicit in the standard that the symbolic name of
such a generated temporary is (sufficiently) unique. A classical
symbol whose name is a UUID would be enough and does not need any
extension of the language.

3. The semantics of the language become more complicated and less
pleasant. The earlier possible invariant that symbols have read-write
invariance would no longer be possible. The reason d'ètre of symbols
would be gone. The user of the language will have to cope with
seemingly overlapping ways to solve problems: When to use
generate-temporaries? When to use string->uninterned-symbol? When to
use macro hygiene and when to rely on uninternedness?

4. Uninterned symbols seem to be an addition of the past that was
before the Scheme's sophisticated macro system became common. The best
way for Scheme to move forward is to simplify things and not to go
back to CL.

5. The lexical syntax is incompatible with the small language where
`|' is a delimiter and `:' is an identifier. Adding uninterned symbols
to the set of datum values is incompatible with the idea that datum
values have read-write invariance.

In fact, as soon as uninterned symbols appear in datum values, they
will have to be interned somehow by AOT compilers anyway because then
they appear in syntax objects which need to be serialised and
deserialised when AOT expanded libraries are written and read-back.

Chez's `string->uninterned-symbol' seems to be a relict from former
versions of Chez. When adding such a symbol to a global environment in
Chez, only the textual name is taken into account. This makes sense
because there would be a space leak otherwise, as environments are not
weak hash tables. In particular, Chez's uninterned symbols cannot be
used reliably to generate unique identifiers in the sense of macro
programming, For Chez, it seems that all new code should use its
gensyms.

To make it precise that uninterned symbols are unique, this SRFI will
need some language saying that uninterned symbols are conceptually
tagged with a location or similar.

Hash tables and other data structures taking symbols as keys lose some
properties and become hard to implement correctly. Before, a table
holding symbols neededn't be weak because (interned) symbols never
became inaccessible. Now, it has to be replaced by a weak table but
that table would have to be able to support both weak keys that can be
garbage collected and keys that can be recreated on demand.

Marc