[I'm not subscribed here (thus the [isocpp-core]).]

> • Current PR says:
> If the static type of the object to be deleted is different from its dynamic type and the selected deallocation function (see below) is not a destroying operator delete, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

For the record, one could easily avoid "shall" here with a strictly phrasing approach:

If the static type of the object to be deleted is different from its dynamic type and the selected deallocation function (see below) is not a destroying operator delete, the behavior is undefined unless the static type is a base class of the dynamic type of the object to be deleted and the static type has a virtual destructor.

(You could then collapse the two "the static type"s.)
 
> • Possible rewrite 1 – just avoid normative words:
> Issue: Deleting an object whose static type is different from its dynamic type and the selected deallocation function is not a destroying operator delete, and:
> * the static type is not a base class of the dynamic type of the object to be deleted; or
> * the static type does not have a virtual destructor.

This is probably an improvement, though, just because there's not much point in reminding the reader in every sentence of the UB annex that what happens in this and that case is that the behavior is undefined. I might massage it as one could the above:

Issue: Deleting an object whose static type S is different from its dynamic type D where the selected deallocation function is not a destroying operator delete and T either is not a base class of D or does not have a virtual destructor.

> • Possible rewrite 2 – condensed paraphrase:
> Issue: Deleting an object of type T, where the operand of the delete-expressions is of type "pointer to U", for certain combinations of T and U.

Making this change (consistently throughout the annex, as one would) causes the annex to not be a _description_ of the undefined behavior in the language (as might be useful in isolation) but a list of _pointers_ to the undefined behavior descriptions in the standard. Which of those is better is a question about the expected usage of the (sub)document.

> Jens suggested that style 2 may be better: It’s less likely to become inconsistent if we ever change the normative rule in the future. It avoids trying to exactly reproduce the rule (we have cross-references for that).

That's true, but one would of course still want to make people check. (Conveniently, the editors would tend to notice a failure to do so, even if not at the best time, because they would hit the \ubdef when applying a paper.)

> Call for feedback: What do you think? Do we prefer style 1, or style 2, or something else?

I don't have a stylistic preference (1 and 2 are both better than the status quo), but I think it's important that we decide which kind of (sub)document we're producing.

Davis