Proposed resolution:

Change [propagation]/7:

-7- Returns: An exception_ptr object that refers to the currently handled exception or a copy of the currently handled exception, or a null exception_ptr object if no exception is being handled. The referenced object remains valid at least as long as there is an exception_ptr that refers to it. If the function needs to allocate memory and the attempt fails, it returns an exception_ptr object that refers to an instance of bad_alloc. It is unspecified whether the return values of two successive calls to current_exception refer to the same exception object. [Note: that is, it is unspecified whether current_exception creates a new copy each time it is called. --end note]

[ Bellevue: ]

Agree the issue is real.

Intent is lifetime is similar to a shared_ptr (and we might even want to consider explicitly saying that it is a shared_ptr< unspecified type >).

We expect that most implementations will use shared_ptr, and the standard should be clear that the exception_ptr type is intended to be something whose semantics are smart-pointer-like so that the user does not need to worry about lifetime management. We still need someone to draught those words - suggest emailing Peter Dimov.

Move to Open.

Without some lifetime guarantee, it is hard to know how this type can be used. Very specifically, I don't see how the current wording would guarantee and exception_ptr caught at the end of one thread could be safely stored and rethrown in another thread - the original motivation for this API.

(Peter Dimov agreed it should be clearer, maybe a non-normative note to explain?)