>> futures spec inspired by SRFI 18: <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FuturesCowan.md>.
>
> A quick look gives me the feeling that this is very close to SRFI-18 (with some SRFI-21 things added) but using a different name (future-… instead of thread-…).  So I don’t see the point in going in that direction, rather than using SRFI-18 as a basis and extending it with new operations.  But then again these new operations are probably going to be more controversial than the established SRFI-18, so why not simply put up SRFI-18 for adoption, and then have a separate document with the extensions?

I'll let John give the definite answer for himself, but when he adds a
new API it's usually due to an obscure reason having to do with
cross-implementation compatibility or working around some restriction on
the mandate of what R7RS-large allowed to do. He is not one to reinvent
the wheel out of vanity or ignorance. R7RS-large is a difficult
balancing act between conflicting expectations; most people (myself
included) tend to mainly be aware of the particular aspects in which
they have the most stake.