See https://github.com/w3c/csswg-drafts/issues/7961, which details some of the problems, including genuine and currently irreconcilable ambiguities, and goes into attempting to make it work by adding convoluted and complex rules and arbitrary lookahead in a way that I really strongly hope gets nixed because it’s awful. (And they’re really only trying to do this because they resolved to make & optional in #7834, which I think was where things started going wrong.)
Sorry, all the irreconcilable ambiguities are conflicts with other, not-yet-accepted proposals, with one exception, a conflict with JS tools that use JSON to spit out CSS. I'd argue that there are other syntax options for those other not-yet-accepted proposals, and this is likely to be a more-used feature than any I saw. And forcing some poorly-designed JS tools to come up with a minor workaround just isn't something I care about.
Is there any conflict with anything that exists in the standard right now?
The parsing time issue is "in the standard now". Even if no rule today matches `property: value { something in brackets }`, that's still at least three tokens (`property`, ':', 'value') to read before bailing out at a bad "property" because values "shouldn't" have things in brackets. (You can build examples with complex CSS selectors where it becomes way more than 3 tokens, as well.)
CSS was designed to be "forgiving" of malformed input, so there's generally no "early" bailout the parser can make, even if it doesn't think it knows which property you are talking about and has a whitelist of specific properties it supports.
