One of the advantages that the Operation Data token provides is that any content is stripped off when an event is sent to the application shim and then added back to the response Status message that is returned. This provides an opportunity to clearly identify the response to a specific event and take any desired actions based on the Status returned. Just to be clear, the examples being discussed here are for events starting in the Vault and then processed on a Subscriber and sent to a connected Application for processing.
As the engine uses the event id to match the response with the original event, there exists occasions where the same Operational Data can be added to multiple Status messages returned for events that have been generated with the same event id. You can see this if a policy results in an a modify action that follows an existing add operation. In some situations, some poor code has resulted in multiple modify operations in a row from the initial event. If there is no unique Operation Data on each of the events, each of the resulting status messages are given the same Operation Data as the initial event when the response is returned from the application shim.