Imagine that you have 3 triggers (W C D - correspondingly Warning, Critical, Disaster severities) for a single item (like free space of a hard drive).
Then you configure dependencies that higher severity triggers hides less ones. I.e. classic dependencies configuration, according to zabbix logic.

Then you do integration with a 3rd party ticketing system (a Tool), where all 3 triggers are sending alerts to. On the Tool you use the tool-specific alerts aggregation, where an existing Warning alert is updated to Critical and later to Disaster levels.
Note - the same alert, not 3 separate ones, coming from zabbix from 3 separate triggers. The aggregation is a must! Used for many other sources of alerts, not only from zabbix.
Uniqueness of the alert on the Tools side is based on (hostname, itemkey) pair. Pretty good and quite reasonable approach, used a lot.

And here is the issue - when Disaster problem is resolved on zabbix server side, it resolves the single alert (Disaster level currently) on the Tool side.
And while on zabbix server the Critical problem is now visible again, there is nothing on the Tool side at all. So Zabbix and the Tool showing different pictures of monitoring.
This is the limitation of zabbix currently.

How the limitation could be resolved - if there would be a separate/new type of Update operation, which would send "a sign" to the Tool that while Disaster trigger is getting resolved/recovered, the Critical problem is getting back visible/existing again.
https://www.zabbix.com/documentation/6.0/en/manual/config/notifications/action/update_operations

We would need to think more how actually it could be implemented and how it could look in zabbix, but it definitely would be really needed feature.