This is a very hard ticket to title to get up votes.
I hope the zendesk Domain logic creators get a chance to read this. 

I have an issue with the domain logic defended enough to warrant you to create a FAQ on your position - https://support.zendesk.com/hc/en-us/articles/4408881694362

This logic rules out ALL of your customers sharing a common business relationship. 

Scenario:
Our customer Z needs to organise products from Company A and have them installed by Company B and have both companies involved if any issues may arise during the project. 
Z does not know (nor care) what ticketing system A and B use and sends one email to both parties (directly) regarding the project issue. In doing so the ticket is currently only created in one of A or B zendesk tenancies. The email is asking A for information so B can do the job, but B only got the ticket and is waiting for A to respond. B and Z are waiting for A who knows nothing about the issue because of this current logic. Z rings A to find out why they have not responded to the repeated emails only for A to explore why they did not get the ticket. 

Based on this scenario (which can be very costly!)  Company A looses faith in the zendesk service.  

Zendesk claims the email has a unique ID that can only exist in one tenancy across the entire zendesk system.  

I propose when the email is received, zendesk search all "To" addresses to compile a list of tenancies in its eco system. For each tenancy create a ticket with tenancy ID+email ID so there is unique tickets for each tenancy (A and B) to action upon. 

The solution your support team gave, was to create two tickets, one for Z and one for B, the problem with this is Z instigated the tickets by email. Z does not know zendesk limitations nor that A and B use zendesk, and therefore A never knows to create 2 tickets. Nor does B know that A has that issue.