Two of the open issues related to @scope are related to defining extensions to the syntax:

• [cascade-6] Unclear proximity for scoped descendant combinator #8380 attempts to resolve complexity in 'scope proximity combinators' (>>/~~)
• [css-cascade-6] Handle sibling-proximity in @scope #7751 proposes an alternative 'sibling-scope' rule for generating DOM-horizontal scopes

Before we get into discussing and resolving on the details, I just want to note that neither is a core requirement for shipping the existing scope syntax. If we want to defer them to a future spec, the current scope rule can ship uninhibited. To consider each one at a time:

• The scope combinators are a syntax sugar over behavior that can already be achieved using @scope - but with the added complexity of resolving multiple subjects from a single selector. These may be worth pursuing, but it's not clear that there is a strong need for them - or that the 'semi-de-sugaring' solution proposed will make sense in practice. To me, these feel non-essential.
• The sibling-scope proposal has a stronger and more distinct use-case, but not an extremely common one. Since it would reflect the @scope rule more precisely, it may also be simpler to spec -- but not trivial.

I think both discussions are worth pursuing. I also think both could be deferred in order to ship the central functionality here.