There are two uses of QMutableEventPoint:

• copying a QEventPoint's properties and allowing manipulation. In this case, the object is an actual QMutableEventPoint, and it's use is ok, albeit made complicated by missing conversions from and to QEventPoint.

• casting a QEventPoint to QMutableEventPoint in order to manipulate properties that QEventPoint doesn't provide getters for. This usage depends on UB (invalid casts and invalid member calls d/t object type mismatch), and we must get rid of it.

My current thinking is that it's ok to have a QMutableEventPoint, as a private subclass of QEventPoint, with explicit conversions from and to QEventPoint, so as to not require casting. At the same time, like mentioned in QTBUG-99563 for QMutable*Event, we could have static setter methods that can act directly on QEventPoints.

I have a working prototype that implements the above two ideas, but the main issue here is the unclear sharing behaviour: most setters neither detach() nor check for d == nullptr, with the exception of setTimestamp() and updateFrom(), which conditionally and unconditionally detach, respectively. This could be handled by only allowing move conversion from/to QEventPoint, which is probably the way to go for the first iteration.