- Most existing versions of `parameterize' evaluate the
   new parameter values in parallel (as in `let'). Is there
   a particular reason why this SRFI insists on doing the
   evaluation in `let*' fashion?

- I'm not sure with this one, but (if I haven't overlooked
   something in the SRFI-18 specification), is the definition
   of `dynamic-bind' in the reference implementation reentrant?
   It might be possible that `current-thread' in the before
   thunk refers to a different thread than the one active in
   the after thunk.

- Is it really desirable to separate parameters into two
   classes (i.e. mutable and (perhaps) non-mutable)? The whole
   specification is uncomfortably vague with respect to non-mutable
   parameters and I don't really see the advantage of having
   the non-thread-local kind. Or is this just an attempt to
   somehow cram some degree of portability in this SRFI?

I propose a much simpler and more portable solution:
(and you won't like it ;-)

1) Dump `make-mutable-parameter'. `make-parameter' returns
    a mutable parameter object.
2) `parameterize' changes the parameters by "swapping", as
    in the traditional implementation.
3) Make all parameters thread-local, child threads inherit
    the parameter-settings of their parents.

cheers,
felix