Normally, a database is set up so that fields with Name/value pairs are connected to the values in the value table. This is not the case with Explore. All ticket field names are thrown in one bucket, and all possible field values, are thrown in another bucket.
Then on each ticket update, instead of asking the system to return the name/value pairs that changed, it returns true/false for "all names that changed" and "all values that changed" and has no way of determining what names belong to what values (especially if multiple fields had no change). This is also why the "changes - previous value", "changes - new value" sets are so enormous and difficult, because literally every possible field value has been thrown into these buckets without any way for the system to limit returning these Values, to the specific field Name that you need.
This also means that you cannot calculate things like, the time from escalation, to the next public reply to the customer, or the time from a ticket being de-escalated, to the next public reply to the customer, or any other of a variety of situations that you'd expect to be able to report on.