Hi,
Yes, this was a deliberate change. Here's the entry from the change log:
Improves the handling of out-of-order data in tags. When outside data, such as OPC or tag references, arrives with timestamps that are out of sequence, the data will be processed by the history system, instead of being ignored.
So the case we were trying to handle is that apparently in some cases, coming from outside OPC servers with buffering, the latest value is delivered before older values are passed through. The tag system previously would publish each change, as you saw, however, the history system would always ignore those values.
This change marks those values as "backfill" values, and processes them through history, but does not publish them. That way, the latest timestamp seen is always represented as the current value.
With that in mind, you might prefer the new methodology. Perhaps you need to have a small buffer and order the values yourself. But if you truly prefer the previous behavior, there is a system parameter you can add to ignition.conf to revert the behavior:
-Dignition.tags.processbackfill=true
Also, I think you DM'd me (or have a different post) about something else that may have changed in this version, that I've been meaning to look at: in 8.1.2, if you have 0 deadband, it will now publish a new value if the timestamp has changed. The motivation for this is that it is the source that should dictate changes, and the tag should not prevent them, especially if the deadband is 0. On the other hand, we adjusted it so that even a small deadband (.1, for example), which previously would not have had an effect on Integers, will now filter those timestamp based changes.
I still want to look at your actual question, though, because I think it has to do with Tag Group based expression execution, and so perhaps in that case, the "source" should not fire events if the value hasn't changed. I'll let you know.