I did recently add a test for one :scope use case: web-platform-tests/wpt#43697

When approving it, @mdubet mentioned a thing that led me to go and test how :scope behaves in the current WebKit implementation:

To my understanding of the spec, the inner rule selector should be :is(:scope .b):is(:scope.x *) with :scope representing any .a elements of the page.

To me, the “any .a elements” sounds incorrect. Per the current specs (https://drafts.csswg.org/css-cascade-6/#scope-effects):

The :scope selector is defined to match the @scope rule’s scoping root.

As I think it is intended, and as it is currently implemented in Chrome, the :scope in this case should match “The scoping root node” (quoting the specs), with the “node” being important, and meaning it should not match just any similar scoping root.

However, the current implementation in Safari Technology Preview seems to treat it as something similar to :where(&) (with the specificity of a pseudo-class), here is a CodePen with an example: https://codepen.io/kizu/pen/WNmeLre

<div class="root outer">
  <div class="test">this should be lightgreen</div>
  <div class="limit">
    <div class="root">
      <div class="test inner">this should be lightgreen</div>
    </div>
  </div>
</div>

@scope (.root) to (.limit) {
  .test {
    background: lightgreen;
  }

  /* This should never match for our HTML structure */
  :scope.outer .test.inner {
    background: tomato;
  }
}

In Chrome, we can see two light-green elements, but in Safari TP the second one is tomato.

I think the way it works in WebKit is due to the misinterpretation of the spec. If this is a case, maybe the spec could be clarified? I think, the minimal clarification could be to add the “node” wording to the :scope's definition, but perhaps a more verbose explanation of what this should mean in practice (could be as a note?) could be added as well.