If I understand @kattrali's proposal correctly, it seems like onFatalError would be something that runs immediately before program termination, since this API doesn't provide any indication of where to continue from or whether the error is considered to be handled. An API like this still seems useful to be able to log backtraces, but to me, the safest thing to do would be to crash without trying to unwind anything.
If we introduced an interface that also allowed the program to continue executing, like what @ktoso is talking about with catching soft faults, I think leaving the crashed subprogram in a hung state, without unwinding it, might be a good incremental step toward improving the robustness of Swift programs. While not ideal, that could still let the supervisor part of your program finish servicing other requests if one crashes, for instance.