This depends on how you model control flow. What's become more common now is to have very explicit control flow modeling so you have pseudo-edges from every place an exception can occur to the catch block (of course fewer with synchronous exceptions).
So when the exception is thrown you keep the frame on the stack, shove your IP, and go to the new handler -- like a function call. From the handler you have five potential exit points:
1) Pop stack, jmp... continue control flow from where the exception took place,if recovery succeeds.
2) Fall out the bottom if it was handled, but not "recovered".
3) Go to next recovery handler in list, if there is one.
4) Unwind.
5) New exception.
With that said, there are as many ways to implement exception handling as there EH mechanisms. Every one of mine I've done pretty differently, but in everyone of them I think could implement condition handling pretty easily.
The difficulty in adding it to the language when modifying the language implementation is an open option is much lower.
Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone. The exception mechanism has to travel up the call stack to find the handler, and can't get back to where it was.
You can fake it in many languages, but you can't retroactively make the language support the behavior. You end up with a nasty mess that, although it may be powerful, is so far removed from the normal idioms of the language everyone you work with will want to kill you for doing it.