Your model is one of the many things that gets solved when
doing closest-exit routing with external peers.
A quick pair of definitions: a customer is someone paying
for transit everywhere through a particular bitpipe; an
external peer is a non-customer with which one exchanges
traffic. For the most part these days, external peers are
not generally also customers.
So, in the model I mentioned, we effectively have two
customers paying to exchange traffic over A, or over A and S.
The fact that one single organization is picking up the bill
is not really relevant, or necessarily even knowable. The
point is that A is being paid for two customer connections,
or A and S are each being paid for one customer connection.
A and S are external peers.
In your model:
Two large carriers, P and Q, are
interconnected at multiple sites, among them X and Y. Let's further suppose
carrier P has two customers, C1 and C2, near X and Y respectively.
We'll assume that P and Q are external peers with no
customer/provider relationship with respect to X and Y.
There are several answers to your questions, depending on
routing policy of both parties. I won't do all variations,
but here are the simple cases:
P does closest-exit routing towards Q; Q takes MEDs to do
best-exit routing towards prefixes P announces, or Q uses an
advisory line to allow P to specify exit points from Q to P
on a per-prefix basis.
Since we have destination-only routing in place in the
Internet, P could dump traffic for C1 on Q at Y, and Q would
route it to X, deliver it to P, which would carry it to C1.
Trivial. Seen it happen. It works.
However, Q cannot do the reverse to P. If Q dumps traffic
for C2 onto P at X, P would dump it right back to Q at X.
In short, you get a routing-loop.
There are ways in which this can be worked around,
for example, by using outgoing routing filters to announce
certain networks to P only at C1 or at C2, or by
using differing AS paths in the announcements and the like.
I imagine that anyone caught doing this deliberately and
without explicit permission (and in practice it has been
pretty easy to catch) would quickly find themselves with no
peering at all, and would just as quickly become a pariah.
(Non peers at X and Y could aim static routes too, which is
equally ugly, and the way around this on the engineering (as
opposed to legal department) front, on top of pariah methods
and the fact that there is the return-traffic problem that
isn't always trivial to deal with, is to break level-2
connectivity between, say, N and Q at X and Y, or to use
various ugly war knobs in people's favourite routers.)
If Q voluntarily allows P or N to do this type of long-haul
routing through Q's backbone (AS healing and the like), then
imho Q is pretty stupid, and not just for the reasons you
Also for some of the reasons you touch on, I think that
having a customer relationship with anyone at X or Y would
also be a silly thing for Q to do.