I agree that it is silly for reference-barrier to be optional.

In MIT Scheme it is defined as an alias for identity-procedure, which
simply returns its argument; that implementation will work as long as
there's no whole-program optimization (or `LTO' as they call it these
days).  If you're going to go out of your way to implement ephemerons
anyway, surely it can't be hard to make reference-barrier work.

I seem to recall that jcowan's argument was that, in the absence of
mutable ephemerons, the idiom

(let ((key (ephemeron-key e))
      (datum (ephemeron-datum e)))
  (if (not (ephemeron-broken? e))
      ...))

is sufficient to reliably operate on an ephemeron.

However, this idiom doesn't help with, say,

(let ((xyz (make-gobbledegook)))
  (store xyz in a weak table somewhere)
  (do a long computation that relies on a cached gobbledegook)
  (reference-barrier xyz))

to ensure that the gobbledegook is not reclaimed until the long
computation which will reuse it is over.  (There's no need for
compiler `reordering'; a reasonable compiler with a strict evaluation
order may just not store xyz in any stack frame that is reachable from
the long computation.)

No comment on procedural issues in the SRFI process.

> Date: Tue, 18 Aug 2020 10:19:44 +0200
> From: Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>
>
> Dear Arthur, John, and Taylor,
>
> I am currently clearing up some old backlogs.
>
> We had the discussion cited below 4 years ago. To recapitulate the upshot
> of the discussion:
>
> (1) Without "reference-barrier", one cannot safely use SRFI 124 in Schemes
> that actually need reference barriers (because of possible reorderings).
> (2) In Schemes that do not need an explicit reference barrier,
> "reference-barrier" is trivially to implement (it can be coded as a no-op).
>
> I want, therefore, to request a PFN saying that "reference-barrier" is not
> optional.  I think this is the only sensible implication.  For
> implementations, this PFN will mean the following: Those that didn't need
> "reference-barrier" can just add it as a no-op. Those that actually did
> need it either already had it or were unusable anyway.
>
> Marc
>
> Am Sa., 27. Aug. 2016 um 20:30 Uhr schrieb Taylor R Campbell <
> xxxxxx@mumble.net>:
>
> >    Date: Sat, 27 Aug 2016 15:40:16 +0000
> >    From: Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>
> >
> >    > It's optional because it has to do something that in a non-trivial
> >    > implementation of ephemerons, such as Racket's, can't always be
> > done.  If
> >    > you need reference barriers, your code willl not be portable to all
> >    > R7RS-large implementations, which is a pity, but there it is.
> >
> >    Is it a hard fact that it may be non-trivial to implement
> >    `reference-barrier' for a given proper implementation of ephemerons?
> >
> > Here's an implementation of reference-barrier that will almost
> > certainly have the desired immediate effect in any implementation,
> > though it may leak space.
> >
> > (define last-reference 0)
> > (define (reference-barrier x)
> >   (let ((y last-reference))
> >     (set! last-reference x)
> >     y))
> >
> > I have a hard time believing that there are any Scheme systems out
> > there in which it is actually difficult to implement reference-barrier
> > correctly.  It should be reliably included.
> >
> >    On the other hand, how do you want to code safely without
> >    `reference-barrier'?
> >
> > Can't.
> >