One of the colleague here. I do agree that the SourceTimestamp definition conflicts with the DataChangeTrigger definition, at least when spec interpreted in a certain way. The main issue is what 'last change of the value' actually means.

Spec says:
DataChangeTrigger: https://reference.opcfoundation.org/Core/Part4/v105/docs/7.10
SourceTimestamp: https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3
ServerTimestamp: https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.4

There is no example in SourceTimestamp, if one would be added, it hopefully would clear any ambiguity in words. Thus, there are (at least) 2 ways to interpret 'last change of the value', and for sake of example assume a numeric DataType:
1) A change can only occur when the numeric value changes to a different numeric value (e.g. '10' cannot happen 2x in row with different SourceTimestamps).
2) A change occurs every time the numeric value is "set into something", regradless what the value previously was, i.e. "an action was done to change something". Just that the result of the action can be that the state remains the same as before, but still a "change-action" was performed. (e.g. '10' can happen multiple times in a row with newer SourceTimestamps)

The SourceTimestamp text Jouni mentioned:
"The sourceTimestamp shall be UTC time and should indicate the time of the last change of the value or statusCode."
could be interpreted in favor of the case of 1. However, if one does that, then the STATUS_VALUE_TIMESTAMP DataChangeTrigger is meaningless. Thus I have personally thought it is the case 2. Though, if that is the case it means it is not possible to obtain the change-time of the value purely via Read (which I think Jouni wanted) or after it has happened, since you cannot know has the same numeric value appeared more than once consecutively already. If you have a live MonitoredItem or access to HistoryRead you could obtain it that way.

To me if the "true data source" of an OPC UA Server has a concept of a timestamp, then that timestamp should always become the SourceTimestamp every time the server sources the data even if the numeric value would remain the same (lets say a temperature sensor that also has it's own timestamp would measure e.g. '10' twice in a row). IF the datasource however doesn't have the concept of a timestamp, it is more complicated. I think it should then be updated every sourcing time, though this does basically make it equivalent to the ServerTimestamp and then a STATUS_VALUE_TIMESTAMP will get a new notification each time (but it would still be the choice of a client to use that filter). In the latter case, the ServerTimestamp is sort of useless unless there is an aggregation Server, but probably that is ok.

If 1. would be the correct choice, then there is a new issue that one cannot anymore know properly when the device made a measurement. Also, it would mean one isn't allowed to use 1:1 the devices timestamp as the UA SourceTimestamp (because the device could get the same measurement more than once in a row).

Additionally, if we look at this from an another angle. A Write https://reference.opcfoundation.org/Core/Part4/v105/docs/5.10.4 can include a SourceTimestamp. And in Table 59 it does say "If the SourceTimestamp or the ServerTimestamp is specified, the Server shall use these values. The Server returns a Bad_WriteNotSupported error if it does not support writing of timestamps."

Thus here if a Client does Write the same numeric value that already is in the node, I think the SourceTimestamp would be the one the Client did Write i.e. that specific SourceTimestamp would be obtained by Read to this node after the Write is completed. Thus, it is more likely that the SourceTimestamp definition in https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3 should be written in a way that makes it clear that it is allowed to have the same value and status, but with a different SourceTimestamps.

Though, it would possibly be a separate case what the SourceTimestamp should be in the cases where it is not defined by a Client in Write or when sourcing a data source that doesn't have the concept of a timestamp.

P.S.
Also, I'm not 100% sure for the Write case for the ServerTimestamp part. The spec says the one given by Client (if it is set) should be used. However, it also "is used to reflect the time that the Server received a Variable value or knew it to be accurate." (7.11.4). Thus isn't it like "now" always (?) since we were just given the value of the node. Thus it shouldn't matter what client has given and instead current time should be used. Additionally. IF our data-source would truly be like a 'client opens connection, writes value, closes connection' -like whenever the value would updated. Wouldn't that mean the ServerTimestamp is always 'now', since if nothing has pushed a value update, it always "knows" that it knows it to be accurate (or technically it never knows it is accurate). So the ServerTimestamp is sort of ... mostly meaningless, at least when the data sources are like this (also, this in my opinion is a true "exception-based" data source, compared to the example of ServerTimestamp, which is sort of a hybrid of a device doing some polling and server magically knowing it's polling rate).

There is nothing wrong in the specification.

It is true that the SourceTimeStamp can only change if the value changes but a value can change two times between two samples which changes the SourceTimeStamp. This can also happen if a client writes a new value and the data source changes is back to original value before the next sample happens.

This was actually the main use case for the trigger to help clients that write values, keep the written value in the display and then want to get a notification if the value was changed back to the old value.

The only potential enhancement would be to descibe this more explicit.