[cascade-6] Unclear proximity for scoped descendant combinator

This combinator [>>] differs from the descendant combinator in that it applies weak scoping proximity to the relationship between A and B.

In simple cases (e.g. A >> B), it's clear what this means, but what about more complex cases? A >> B >> ... >> Z, A:has(B >> C), :is, :not?

It doesn't seem easy to spec an easily understandable behavior for >> given the amount of flexibility we have in selectors. Perhaps we should revisit whether >> really is needed at all.

If we do keep it, we should avoid introducing complexity that would be detrimental to performance:

• Avoid a variable number of cascade criteria. Proximity should be a single number for the whole declaration.
• Avoid a proximity value which depends on multiple successful matches of the same selector. (E.g. imagine an :is(X,Y) which matches for both X and Y but with different proximities). Once we find a match, we can not continue looking for "better" matches.

Note: The proposed selector scoping notation does not have any of these issues, so perhaps we should continue to explore that direction instead, if we really want "inline" scoping.

Start by reading the issue and the linked CSS Cascade 6 scope-combinator section, then review the examples involving chained combinators, :has(), :is(), and :not(). Done requires a resolved specification direction for proximity semantics, or a decision to pursue selector scoping instead, without introducing the stated performance concerns.