Alexander Terekhov:
But exception translation can be done much more sensibly without unexpected().
... or not be done at all, which is even more sensible. Regardless; in the pre-Abrahams era, when exception specifications were designed, the prevailing mindset was that the set of exception types a function can throw is of much importance, and that subsystems would design their own exception hierarchies and never throw something outside their hierarchy. Under these assumptions, exception specs and unexpected() do work. You can do
void g() throw(Y) { translate_any_exception_to<Y>(f); }
but this requires intrusive modifications of the g subsystem which you can sometimes avoid with a sufficiently smart unexpected handler. It is not realistic to expect this behavior to be changed, but it might be possible to add another handler, separate from std::unexpected, that is invoked prior to stack unwinding. But I still do not understand your motivation for insisting that this is the correct way to do things. What specific practical problems does this solve?