content inside ::marker.
With the code above, Chrome and Firefox render a red " - ", while Safari renders a red circle instead.
The confusing part is that the @supports condition succeeds even though the declaration is not actually supported in that specific context.
To be fair, this is probably less about browsers "moving" (or more accurately "parsing") nested @supports rules to the top level or in general context, and more about how @supports itself is defined. The feature checks if a declaration is generally valid, not if it is syntactically valid for a specific selector or pseudo-element context.
Maybe one solution would be to extend and (or introduce a new operator or function) so @supports checks can validate combinations rather than independent features. For example:
@supports selector(::marker) and (content: " - ")
or
@supports selector(::marker) xand (content: " - ")
or
@supports rule(::marker { content: " - " })
That would allow to test if a declaration truly works within a given rendering context, instead of only checking if the syntax is recognized.
Another (more ideal) solution would be for browsers to evaluate @supports relative to the scope in which it appears. But that may require too much computation... but hey! they said the same about :has(), and look at it go today!
Note: I know container and style queries may be a workaround, but they only have partial support and can only check for custom properties, not declarations (at least at the moment). Their use could help but wouldn't remove the misleading/limited nature of nested @supports.