To quote Neil’s talk last month “it depends”. There are a lot of ways to model entities and their relations, and some of them are very dependent on what a business thinks, or how your sources are limited. In my opinion, the fact that you are talking about Case entities and Issue entities as separate things which have non-overlapping sets suggests that they are separate entities that happen to join up sometimes. To add to complication, the business does not regard them as separate, even though they are.
To me the true test of whether they are separate would be “if a Case exists, and an Issue also exists, is it possible to join them, and from that point they are regarded as the same thing?”.
If the answer to that is yes, then you need to model Case and Issue separately, and add a same-as-link between the two hubs. This can then be visualised going business-ward in the datastream as one “Customer Service Incident” by joining the two entities.
If the answer is no, then there is the question of “is there a common identifier between the systems that isn’t the internal Id of the system?” If the answer to that is no, then they should probably still be treated as separate, as above.
If the answer is yes (there is a common identifier), then that should be your business key, with a unified entity feeding from both systems.