...or not. I can't help feeling there is real value to having the exception handler being run in the same dynamic context as when raise was originally invoked -- for example supporting a runtime debugger. With the suggested I proposed, if, say, a divide-by-zero exception "escapes" the guard tests, information about the dynamic state when the exception occurred is lost.
With the spec as it stands, you can achieve the effect of avoiding "wind-thrash" by adding (else (raise c)) to your guard forms if you didn't already have an else.
Another hypothetical alternative would be for the TEST forms of the guard's implicit COND to be evaluated in the exception handler (dynamic context of the raise), but then the consequent forms of a matching test be evaluated in the context of the GUARD -- the handler would be able to avoid unwinding if all the tests return #f and there is no else clause. Something to ponder... I'm not sure this is such a great idea either because the semantics would be non-intuitive to the user who thinks the implicit COND is literally a COND.