The idea of an alternative return address - that is, allow the calling convention to pass more than on return instruction pointer - seems both simple to implement and really useful. I guess in the modern gotoless world the trouble is structuring the syntax around the call.
Then you just passed them during function call, e.g. "handle = open_file(input_file_name, open_flags, FailedToOpenInputFile);"
The error handlers at the end of the body of the invoking function were just labelled appropriately.
Writing a label like FailedToOpenInputFile: before an error handler is certainly much simpler and more obvious than strange workarounds for exception identification, like inventing a dedicated data type for each possible error, as in C++.
This could be an easy syntax extension, but then the only advantage remains the more efficient hardware implementation of the error handling.
In that case you no longer have the separation in program text between the normal execution path and the error handlers, which removes visual clutter.
If called function is responsible to clear stack, like in Pascal or Forth, then yep, multiple return points are easy to implement and useful to implement something like switch operator. I used it in Pascal, when I was in school. Just pop old return address from stack and push new one.
Like for the C null-terminated strings, there are many alternative ways to implement variable argument lists and all of them have already been used many years before the first C compilers, e.g. passing a hidden parameter count or implementing transparently for the programmer any printf-like functions as vprintf-like functions.
With the alternative implementations, the stack should always be freed in the invoked function, which also enables various other important features, e.g. tail-call optimization.