PS Maybe the gist of my critique is the following:

Long-term Schemer: "Scheme is like a diamond, the most elegant
language on the planet."

Scheme Newbie: "Really? What is the reason?"

Long-term Schemer: "Because in Scheme, we do not pile feature on top
of feature. Instead, the language becomes so expressive by choosing
only few primitives and data types and also removing the weaknesses
and restrictions that would prevent them to apply in maximal
generality.

Scheme Newbie: "Small number, okay. But then, tell me, why should I
use symbols? The language has already strings!"

Long-term Schemer: "Well, symbols are objects whose usefulness rests
on the fact that two symbols are identical [in the sense of eqv?] if
and only if their names are spelled the same way. For instance, they
can be used the way enumerated values are used in other languages.

Scheme Newbie: "I understand. That's a pretty cool guarantee and tells
me why Scheme also has symbols."

Long-term Schemer: "But then it will surprise you to learn that there
are also symbols that are not identical although their names are
spelled the same way."

Scheme Newbie: "What? But then these are like strings, and we already
have strings!"

Long-term Schemer: ...

Am Fr., 24. Jan. 2025 um 13:53 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> 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