Currently, when you create a Trigger, it produces a generic name based on the type of Trigger it is (example: "[EventTrigger]", "[PropertyChangedTrigger]", etc...

This works quite similarly to Elements in the Navigator containing "[Grid]", "[StackPanel]", etc...

In both cases, renaming a Trigger in the Triggers Panel (or Element in the Navigator) clears this default [Bracketed] identifier.

However, where they differ is that if you give a custom name to an Element in the Navigator, they still:
a) Retain a unique icon per Element type
b) Can be hovered to reveal their Element type in a Tooltip
c) Can be identified via the Properties Panel, via a label at the very top of the panel, stating the Element name.

In the case of a Trigger, on the other hand, if you rename a Trigger, all ability to identify what type of Trigger it is, is lost. (Unless you are an advanced user enough to identify a Trigger type solely from the selection of Trigger Properties visible in its Properties Panel).

This results in making it incredibly difficult to replicate Trigger setups, as well as making it incredibly difficult to find ones way around a file's Triggers. The only real countermeasure at the moment, is to ensure to have the presence of mind to concatenate the Trigger type in the custom name when first renaming it (eg: "IndexUpOnClick_EventTrigger".

See attached image 1 "Identification" for a side-by-side comparison of Triggers vs Elements.

Proposal:

In this case, and up for discussion as always, but I may recommend replicating some of the UI/UX of Elements that address this, but applying them to the context of Triggers.

See attached Image 2 "Proposal".

(A stretch to this would be for each Trigger type to have unique icons too (just like all Elements have unique icons), but its non-essential compared to a text-based ID.)