Same endpoint name with different db schemas causes unexpected behaviour

[jpalac]

Scenario

It is possible to use different schemas for endpoints in the transport,
If using pub/sub, all endpoints in the system must be configured to use the same subscription table

If schemas are used to separate/group different system functionality (e.g. sales and stocktake), then it's possible that there might be the same endpoint names in both: sales.office, stocktake.office

Pub/Sub

This causes a problem in pub/sub as the subscription table uses the Endpoint and Topic fields as the key, which would be the same for each endpoint in the above scenario, since the schema is not part of the endpoint name - it is stored in the QueueAddress field that is not part of the table key.

If using EnableInstallers, if both sales.office and stocktake.office subscribe to an OfficeHoursChanged event, then the first endpoint that starts records its subscription in the SubscriptionRouting table, and the last endpoint to start would then overwrite that record with its subscription. This results in only one of the endpoints being subscribed to the event.

Because of the primary key in the subscription table. the subscriptions cannot be corrected by creating them manually.

Audit/Monitoring

Two known endpoints are registered, but since they are named the same, they are seen as the same logical endpoint (2 different instances of the same endpoint), where in fact they could be very different logical endpoints.
It is also not possible to easily distinguish them in ServicePulse if they are running on the same host, as they are both showing up as office@hostname

Suggested Improvement

Introduce some kind of validation for this, as it seems to put the system in an invalid state.