@floca made some good points, in that the current behaviour might violate the principle of least astonishment as a developer probably assumes any change to any member of a data node constitutes a change of the data node itself and is thus ModifiedEvent-worthy

He suggests:

1. If there are good reasons for this not be the case to explicitly document those reasons and suggest workarounds/alternatives if one wants to keep up with changes in the property list
2. If this is in fact not intended behaviour fix the ModifiedEvent to be fired in those cases
3. Provide an additional EventSlot to inform about property changes

In T22322#91228, @goch wrote:

1. If there are good reasons for this not be the case to explicitly document those reasons and suggest workarounds/alternatives if one wants to keep up with changes in the property list

Small addition to this suggestion: The "workarround pattern" shoud also cover use cases where you don't know the existing property lists (e.g. dynamically added render window an its specific propertylist; so you cannot directly register events there), but you wan't to know if they change, because you assume a node as modified if one of its property lists changes.

Interesting discussion. I agree that either all propertylists or none should mark the DataNode modified.

There is another tiny detail that could be cleaned up while on the subject: DataNode::GetPropertylist(..) const returns non-const property lists. This allows removing properties from const DataNodes without having to use a suspicious const_cast<>.

Came across this task again. It is still open for discussion, so we might consider this in T23721?

We discussed it today with the following results:

1. It is a flaw.
2. We have to go the hard way *sigh*
   1. Modification of any parts of a node (Any node property, property list of any context, data, data pointer) should also flag the node as modify and trigger a ModifyNode in the data storage.
   2. 2.1 will likely result on too much (more false positives than before) rendering updates. If this is a problem, a helper structure to check for more specific modification (answering the question: was the specific property or propertylist modified since last time) should be implemented and the renderer should be refactored to use this structure.

Addition due to the discussion of T27307:

1. it is still a flaw and should be handeled consistently
2. But details of what/when to change or signal change are currently open for discussion. So this task should not be tackeled, without good reasons, before T27307 is clarified.