My initial post, as written, does say that explicitly freed references
solve the thread-related problems with SCHEME_EXTRACT_VALUE_POINTER
and SCHEME_EXTRACT_STRING.  But that's not right; as described,
references don't have anything to do with that problem.

I inserted the paragraph about SCHEME_EXTRACT_* after I'd written
everything else, and didn't notice that I'd changed the antecedent of
"this problem" in the next paragraph.

Here is how that section should read:

  The proposal states that "the garbage collector may run whenever an
  object is allocated in the heap."  In context, I think that really
  means, "the garbage collector may *only* run..."  In a multi-threaded
  context, I think this must mean that the collector may only run when
  any thread allocates an object on the heap, which isn't much of a
  restriction at all; the collector can run at any time.

  If that is so, then the way the proposal suggests C code should refer
  to Scheme values makes it impossible for the collector to find and
  relocate heap references.  The C compiler may have stashed them
  anywhere, in disguised forms, and it is probably unwilling to tell you
  much about where they are at any given time.

  The Java Native Interface handles this problem by essentially
  forbidding C code from ever referring directly to a GC'd object.
  Instead, C code may only handle "references" to GC'd objects.  This
  restriction is enforced by the type system.  References are explicitly
  freed objects, which is way people are accustomed to working in C.
  And because the explicit-free model is a complete pain in the neck,
  the JNI tries to ease that pain by segregating references into "local"
  and "global", where "local" references are freed for you at a
  convenient time.

  Another issue is that, if a collection could occur at any time, the
  values returned by macros like SCHEME_EXTRACT_VALUE_POINTER and
  EXTRACT_STRING can't be trusted long enough to be useful.  This can
  be solved in various ways; one idea is sketched in:

    http://sources.redhat.com/ml/guile/1999-01/msg00093.html