We can't to do anything about "panics" (hard failures, which can occur anywhere in the middle of an incomplete expression, at any stack level, even from just looking up a word that's a typo). No hope of graceful handling there...
...BUT we can theoretically do something about the new and novel definitional ERROR! antiforms 
which emerge from the overall step, that have not yet been promoted to a PANIC. Because the ERROR! antiform is a legitimate evaluation product, and the flow of control has not yet been broken.
(And luckily, all meaningfully interceptible errors are definitional. Read the above link to understand why.)
Though It Turns Out To Be Tricky. 
EVALUATE:STEP gives back a multi-result pack, with the position as the first pack item, and the synthesized value as the second.
Usually if a function returns an ERROR!... we tend to say that's the only thing it can return. But in the case of EVALUATE:STEP we want both an error antiform and a position.
This means putting ERROR! antiforms in PACK, which is a little bit of a thorn.
Are There Alternative Approaches To ERROR! in PACK?
The expression completion position could be a field in the error itself.
Using some overlong descriptive names to illustrate:
[pos value]: evaluate:step [1 / 0 10 + 20] except e -> [
if e.id = 'raised-error-in-evaluate-next [
assert [e.error.id = 'divide-by-zero] ; actual error is wrapped in e
pos: e.resume-position ; e.g. [10 + 20]
] else [
panic e ; some other error
]
]
There are more mundane approaches, such as adding :EXCEPT such that EVALUATE:STEP:EXCEPT produces a ~[pos value warning]~ pack instead of just a ~[pos value]~ pack. Then you have to remember to check that the warning (non-antiform ERROR!) is not NULL on all paths. That sounds less foolproof.