And why they also send the same value to prop8 and event 8.
With the ADCL way of doing it, using components, it is possible to simply map %event.message.event% to an eVar.
So you'd have eg.
component id (map to evar1)
component title (map to evar2)
component resource type (map to evar3)
And then instead of the rule "CTA Button" with a condition, you could just have a single rule:
"Component User Interaction Type" / "Component Event Type"
which you can map directly in setVariables from %event.message.event% to an eVar4
Then in reports
Couldn't you just do this
[Component Resource Type]
[Component User Interaction Type]
( dimensions in  and metrics in ** )
Of course I can see that the Button Id (evar) + CTA Click (success event) metric is a bit shorter, but since we're encouraged to use a single report suite for many projects, I think it could potentially become a scalability issue, if we don't try to keep the evar/prop/events to a minimum, due to the very limited amount of evars, props and success events for the whole report suite.
Using a single evar for all component ids and breaking it down like I just showed is a bit more verbose, but you also only need 3 evars - 1 for component id, component resource type and 1 for component user interaction type.. And the you're not limited to only component type "button" or "CTA Button", but can use it for Tabs, Accordions....everything.
I might be missing some important reasonings / details which is why I'm asking these questions. Is it better to set up more rules, using conditions to filter per type and map to different evars per rule or does it make sense what I'm suggesting?