One way to achieve this would be to specify that the dynamic extent of (srfi 154) is bounded in space by the set of continuation marks, parameterizations, and the installed dynamic-wind handlers.
What do you think about such a formulation?
So, the statement sounds true, but the "bounded-in-space" part doesn't really address the issue resolved by reduced-dynamic-extent, so it might be misleading. I concur that the semantics implied by the term "dynamic extent" encompass continuation marks, parameters, dynamic wind handlers, and the exception handler (which could be implemented in terms of any of the prior three). In the future, there might even be more distinct aspects of dynamic-extent. It's up to (srfi 154) to aggregate all of these.
3) One reason why I wrote (srfi 154) and (srfi 157) was to specify the necessary primitives so that (srfi 155) could be portably implemented on top of this.
To retain that, we will have export something like "reduced-dynamic-extent" in (srfi 154). I agree with you that "reduced-dynamic-extent" is not a pretty primitive and won't be used a lot. On the other hand, without such a procedure, dynamic extent objects are simply black boxes and one cannot do much with them except for reinstalling them.
Or would a procedure that captured the dynamic extent of the caller (and not the current one) be sufficient?
Are you asking if call-with-current-dynamic-extent solves all our problems and avoids the need for reduced-dynamic-extent? No. I tried that. It makes it possible for with-dynamic-extent to call the thunk in tail context when the wind handlers are not changing (as my sample code exploits). So, for cases like:
(define (loop)
(parameterize ((foo (cons 42 43)))
(delay-force (loop))))
...the parameterization's all happen with flag = #t, (including the invisible one for tail-call-detector!) so the mark set does not grow in size and the bounded-space test passes. However, this turns out to be a very degenerate case -- none of the other bounded-space tests exhibit this, so reduction is still needed.
If that's not what you're asking, then I'm confused by your question. ;-)
So it sounds like you want something like reduced-dynamic-extent in (srfi 154), so that (srfi 155) can be written portably - sounds good.
4) Eventually, I think I will implement this in the Inferior Scheme system that I am using to demonstrate (srfi 157). Then, this can be added to (srfi 154) and (srfi 155) to have a sample implementation with correct space and time behavior.
When I have more time, I was going try to simulate your inferior scheme and see if I can prove everything over again in that model - but I'm pretty booked up for next 2-3 weeks.