I would like to make the following hopefully constructively read
suggestion that gives implementations enough freedom but also allows
implementations to address the points I raised in the previous post:

(1) Provide only a single procedure

(generate-symbol [pretty-name])

that returns a symbol (in the sense of `symbol?') that may or may not
be interned and that is guaranteed to be different in practice from
any other symbol (*). An implementation may use PRETTY-NAME for
printing purposes.

(2) Drop any lexical syntax (**).

With (1) and (2):

(a) the SRFI can be portably implemented (using UUIDs)
(b) it can also be implemented using native gensyms or uninterned symbols
(c) all use cases are covered
(d) it does not interfere with any existing semantics

--

(*) This has to be worded more carefully, of course.

(**) Objects that cannot be read back (faithfully) are usually written
in some unparsable form like #<...>. Adding lexical syntax that can be
written back makes no sense when the object that is read has no
meaningful connection to the written one. There is also no compelling
rationale for the introduction of lexical syntax. (Of course, vectors
and pairs also do not read back exactly when `eq?` is used, but they
do when `equal?` is used, and the latter is the meaningful equivalence
relation for Scheme datum values. As `equal?` must be the same as
`eq?` for symbols by R7RS, it cannot be fixed for uninterned symbols.

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