Thank you for bringing this up!
This is a design limitation currently. There is no deduplication logic in place to support this usage scenario.
I can see 2 approaches here, an implicit and an explicit one.
Implicit: the Connector runtime compares the properties of each connector instance and decides based on certain rules whether 2 elements represent different connector instances or the same one. Some properties are handled by the runtime (e.g. activation condition, error & response mapping), so the runtime would still have to remember the original elements and map them to the actual connector instances (threads) it created.
Explicit: same as the above, but the runtime does not rely on implicit rules and property comparison. Instead, we could introduce a new property deduplicationId that would allow to define the desired behavior during process modeling. Elements with the same deduplicationId and connector type lead to the creation of the same connector instance. This provides more flexibility, but we might want to introduce additional validation to make sure connectors are actually equal in terms of properties.
We will discuss within the team and decide how we could implement this and which approach we prefer. I will update this thread when I have news.
In the meantime, I can suggest that you use one element per connector in your process, e.g. by modeling only one event and then analyzing its payload using a Script Task to route the message based on its status.