Additional note, January, 2022:

See also library issues 1265 and 3652.

Notes from the October, 2018 teleconference:

There are a number of unanswered questions in the current wording, including the impact on the current exception (whether it still exists) after a longjmp out of a handler, the impact on the initialization of locks if jumping from the initialization of a local static data member, etc. One thought was to restrict use of longjmp to “plain C functions”. Another was to say if the program would have different behavior via the use of exceptions the behavior is undefined. There was no consensus on how to proceed.

According to 17.13.3 [csetjmp.syn] paragraph 2,

A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any automatic objects.

The intent is clear, that transferring control from point A to point B via longjmp has undefined behavior if throwing an exception at point A and catching it at point B would invoke non-trivial destructors. The wording could be more precise.

See also the corresponding editorial issue for additional discussion.