All interesting discussions aside...

It would be nice if the SRFI stated explicitly what we all hope and
assume: that a continuation captured by one thread can be invoked by
other threads.

One could argue that it should be obvious --- after all, we don't have
to specify that `car' still works, right?  However, since such a
requirement would conflict with several existing call/cc
implementations, many people will be under pressure to make the
decision the other way.  I hope the SRFI will make an explicit
statement to prevent this possibility.  Such a statement probably
won't prevent people from creating incompatible implementations, but
it will at least encourage them to recognize the incompatibilities,
and warn their users.

Actually, with my question about memory coherence, I guess I really am
asking the SRFI to specify how / under what conditions `car' still
works.

In general, while I definitely appreciate Marc making the effort to
put down a threading proposal, I feel this SRFI doesn't really address
a lot of important questions about what concurrent execution really
means.  For example, in the absence of a disclaimer about memory
coherency in the style of the POSIX or Java specs, you need to make
some statement about what constitutes an "atomic" action.  It's not
something you can guess from the SRFI plus RnRS.  Without that, I
think there's a danger that the SRFI will be useful only on naive
thread implementations, and provide insufficient guidance for
implementors trying to support true multi-processor systems on
real-world hardware.