The cascading spec defines cascading by encapsulation context as:

When comparing two declarations that are sourced from different encapsulation contexts, then for normal rules the declaration from the outer context wins, and for important rules the declaration from the inner context wins. For this purpose, [DOM] tree contexts are considered to be nested in shadow-including tree order.

This doesn't say what happens when comparing declarations from encapsulation contexts that are not directly inside or outside of each other.

I don't think this is relevant in CSS today. However if either of the following happens:

• we define ::part() as a part-like pseudo-element in [css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like #10794 and thus allow it after ::slotted()
• we make a /slotted/ combinator as discussed in [css-shadow-parts] Make ::slotted() a combinator #7922

then I think we need to define the cascading order between sibling encapsulation context. For example, if you have an element A (with a shadow DOM that exposes a part P) that is itself slotted into the shadow DOM of a different element B, then this would be needed to define how a regular style styling the P element inside the A shadow DOM cascades with a ::slotted()::part() style inside of the B shadow DOM that styles the same element.

Maybe the reference to shadow-including-tree-order is intended to define this, but if it is it probably needs language more specific than "inside" and "outside".

(It might be both extra implementation complexity and possibly also a source of author confusion if the rules from sibling encapsulation contexts mix with each other as thought they're at the same "context" level.)