[lifthrasiir]

To elaborate why you need unlimited lookahead, consider the following:

    h1:has(+ p) { something: anything; } h1 { something: nothing; }
    everything: has(+ p) { something: anything; }; h1 { something: nothing; }

Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a property name to blur a line further. So in order to see if the first block is a rule or a property, you absolutely have to read up to the first `;`, excluding nested braces and alikes.

That said, the main problem is that the property syntax is overly forgiving, not that the nested rule syntax is problematic. Something akin to JS `use strict` should be able to restrict the property syntax enough to allow the nested rule syntax without unlimited lookahead.

[somishere]

First up, anything starting with a .#* is a selector. Secondly, if you're selective about valid tokens then how many tokens are both a valid selector and property name? Probably custom only? And the number of times you'd find a pseudo selector on one of these? We're rapidly approaching extreme edge case territory here.

Also, looking at your second line: I would say the second part (starting at the semicolon before the h1), is invalidated by the semicolon. No need to lookahead or read up to the semicolon. The first part would always be evaluated first, up to the closing curly bracket. The second part would fail at the first character. I'm looking at this on a phone so maybe I've misread?

Edit: I should add, I'm not disagreeing with your point (I don't think!), just emphasising it

[lifthrasiir]

Pretty much late edit: in the second line `: has` to be `:has` with no whitespace (as CSS parsers do care about whitespaces in some contexts).