Proposed resolution:

Add the following exemption clause to [res.on.exception.handling]:

A function may throw a type not listed in its Throws clause so long as it is derived from a class named in the Throws clause, and would be caught by an exception handler for the base type.

[ Bellevue: ]

Is issue bigger than library?

No - Core are already very clear about their wording, which is inspiration for the issue.

While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.

Accept the broad view and move to ready

I understand that the attempt to copy an exception may run out of memory, but I believe this is the only part of the standard that mandates failure with specifically bad_alloc, as opposed to allowing an implementation-defined type derived from bad_alloc. For instance, the Core language for a failed new expression is:

Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception of a type that would match a handler (15.3) of type std::bad_alloc (18.5.2.1).

I think we should allow similar freedom here (or add a blanket compatible-exception freedom paragraph in 17)

I prefer the clause 17 approach myself, and maybe clean up any outstanding wording that could also rely on it.

Although filed against a specific case, this issue is a problem throughout the library.