Thinking about the same problem with SYS.UTIL/RECOVER, I realized it's kind of a matter of phrasing... in that if your construct is phrased in the affirmative (e.g. SANDBOX), you can use EXCEPT.
So if instead of calling it RESCUE it was called something else, like... I dunno, for the sake of argument let's just call it SEQUENTIAL:
value: sequential [
expr1
expr2
expr3
] except e -> [
; one of those expressions returned an ERROR!
]
If you haven't realized it until now--that's what RESCUE is doing that's different from EVAL. EVAL will give you a definitional error but only from the last operation.
This does imply that maybe RESCUE could be phrased as a refinement to EVAL, to say "return an error early from steps that give ERROR!".
EVAL:TRAP may actually kind of make sense here.
When you think about what TRAP does, it's a tool for functions when you are in the middle of them in an execution step, and you want that step to bubble the error out.
You don't need to use TRAP on the RETURN of a function, the ERROR! just gets passed to the RETURN.
So if you're asking an EVAL to TRAP, you wouldn't mean "on the last step". You must mean on its intermediate steps.
There's probably other options like EVAL:INTERCEPT or EVAL:ABRUPT but at the moment I kind of like EVAL:TRAP.
I definitely like the idea of getting rid of ENRESCUE, so this direction is appealing. More as the situation evolves.