Then said row is actually owned by nobody, and the problem solves itself. Your many-to-many table will have a row for each connection, and those rows will have a tenant_id. But that's a normal database problem that will essentially always require joins, at that point -- it's not complicated by this approach.

(Alternatively, your row might have two tenant IDs embedded directly in it by the nature of the shared connection, like "owner_id" and "renter_id" for a property, for example, and again, you're fine because you can use those IDs for a query very easily.)

In a great number of (probably most) business-to-business software domains, most rows are only relevant to one tenant at a time. It’s a partition/shard key, basically: queries will only uncommonly retrieve rows for more than one tenant at a time.

Hassles emerge when the tenant that owns a row changes (client splits or mergers), but even then this is a common and robust architecture pattern.