I apologize for the long delay in moving SRFI-39 forward...

There is clearly discord in how dynamic binding should behave in the
presence of threads.  On the other hand, when threads are not
involved, it seems that we all agree on how dynamic binding should
work.

It appears that the best solution in this case is to separate the
issues into several SRFIs.  SRFI-39 can specify the parameter API and
the behaviour in the absence of threads.  It will be up to individual
thread SRFIs to specify a particular semantics to dynamic binding.

If anyone objects to this approach please let me know.  Otherwise I
will revise the SRFI accordingly.

There is however the issue of the interaction of dynamic binding and
the DELAY special form.  In my opinion the body of the DELAY form
should be evaluated in the same dynamic environment as the DELAY form
itself.  For example in the code

  (with-output-to-file "foo"
    (lambda ()
      (let ((x (delay (display "hello"))))
        (with-output-to-file "bar"
          (lambda ()
            (display "world")
            (force x))))))

we want "hello" to go to the file "foo" and "world" to go to the file
"bar".  This is consistent with the concept of delaying the
computation (you only want to change **when** the computation is
performed, not **what** the computation performs).  If this
inheritance did not happen, the DELAY form would lose modularity (in
the sense that the one writing the DELAY expression would have to take
into account all the possible places where the promise is forced).
This implies that if an exception is raised by the body of a DELAY
form, it is the exception handler that was current at the DELAY form
that is invoked.  I think this makes sense, but I'd like a discussion
on this before moving ahead with the rewrite.

Marc