In addition, I am aware of the following issues:

expr.ref.not.similar – the stable identifier should be changed to something that reflects it's actually about member access

expr.add.polymorphic – it's a weird choice of stable identifier as it's not actually bout polymorphism – I would change to expr.add.not.similar, to be consistent with expr.ref.not.similar

expr.ass.overlap – change to expr.assign.overlap

Many of the cases where you suggest splitting up UB into multiple entries don't seem to be really needed --- i think it might help for us to pin down what exactly we consider worth having distinct entries.

For now, I think we don't need to get more granular than absolutely needed, as long as we cover everything. we can always refine the categorization later if we need to. My priority at the moment is to be sure we have captured everything first before we try to over-explain with more fine-grained categories.

You are right that covering everything is more important than granularity and we can do this later, but my counter-argument is that doing it now is quick and easy and doing it later will be more expensive and complicated – there aren't any downsides to doing it now as far as I'm aware.

Note also that if every explicit mention of the word "undefined" in the Standard is immediately followed by an \ubdef, there is no ambiguity about us having covered them all and about which part each \ubdef actually refers to. You can achieve that with the following edits:

expr.delete.mismatch should be split into expr.delete.mismatch and expr.delete.array.mismatch. We already have a case where an instance of UB was split into single-object and array versions: expr.delete.dynamic.type.differ and expr.delete.dynamic.array.dynamic.type.differ. We should be consistent.

1a.
As a related but separate issue, the existing stable identifier "expr.delete.dynamic.array.dynamic.type.differ" seems weirdly repetitive, it should just be "expr.delete.array.dynamic.type.differ".

class.cdtor.convert.or.form.pointer should be split into class.cdtor.convert.pointer and class.cdtor.form.pointer. Those are different cases that warrant different examples and different error messages. The former is about converting a pointer the object itself, whereas the latter is about accessing its members. There are subtle differences between the two cases that would benefit from being pointed out.

expr.dynamic.cast.lifetime should be split into expr.dynamic.cast.lifetime.pointer and expr.dynamic.cast.lifetime.glvalue. The main reason is again consistency – we already do this for lifetime.outside.pointer and lifetime.outside.glvalue.

intro.object.implicit.create should be split into intro.object.implicit.create.object for "If no such set of objects would give the program defined behavior, ..." and intro.object.implicit.create.ptr for "If no such pointer value would give the program defined behavior, ...". The reason is that it is actually quite hard to figure out exactly when this is UB and when this isn't and to come up with examples. The examples for these two cases are subtly different and having them listed separately will greatly help with understanding.