Date: Tue, 27 Oct 2015 09:25:35 -0400
   From: John Cowan <xxxxxx@mercury.ccil.org>

   Taylor R Campbell scripsit:

   > Not true: it is found in MIT Scheme, and used nontrivially there.

   *sigh*  I need to keep firmly in mind that MIT Scheme documentation
   isn't authoritative.  Thanks.  I'll add it.

Fixed in the MIT Scheme reference manual.

   > I don't understand your objection to SET-EPHEMERON-DATUM!, by the way.
   > A concurrent GC needs to handle racing mutation by the mutator anyway.

   Be that as it may (and my meaning is that proper ephemeron support already
   adds an additional layer of complexity to the GC without piling Ossa on
   Pelion), we have plenty of precedent for standardizing the intersection
   of implementations.  Is there any benefit to mutable ephemerons over
   ephemerons holding mutable boxes, if you are careful to ensure that the
   object is never referred to outside its box except transiently?
   If so, I'm not seeing it, but I am "only an egg" in ephemeron matters.

An ephemeron whose datum is a mutable box may work.