I think I didn't understand the following sentence correctly:

If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration

So color: invalid-value does not match <declaration>. I guess unknown-property: var(--custom) is also invalid. It is a bit unfortunate that:

• the above sentence does not say explicitly "if a processor does not implement the property and the value given, with a usable level of support"*
• <declaration> is inconsistent with <declaration-value> and <any-value>, which accept arbitrary values

This doesn't seem adequately addressed, to me.

Right, sorry:

1. <declaration> still needs to reference a <dfn> somewhere
2. I was wrong about unknown: 1 or color: invalid not matching <declaration>

I was wrong because browsers accept @import 'sheet.css' supports(unknown: 1); (but do not apply the stylesheet). The difference between accept and support confuses me in:

If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration or claim support for it.

That said, (unknown: 1) or (color: invalid) matching <general-enclosed> instead of (<declaration>) seems sane to me because they do not need to be re-evaluated, similarly as @media (unknown) {} never needs to be re-evaluated.

This could be achieved by treating the result of matching <supports-decl> (instead of <declaration>) as a syntax error when it fails to be parsed against the grammar, similarly as an unknown media feature name or an invalid value according to the media feature value definition, matches <general-enclosed> (it is evaluated to unknown).

@cdoublev do you have spec text suggestions to differentiate "accept" and "support", here?

I just applied your earlier suggested clarification:

both the property and the value given,

To clarify my previous comment, since it took me a few minutes to remember...

If unknown: 1 or color: invalid were not matching <declaration>, then @import 'sheet.css' supports(unknown: 1) would be invalid, which does not conform to the spec. The grammar is @import ... supports(<declaration>) (simplified).

With @supports (unknown: 1) {}, the grammar is @supports (<declaration> | <any-value>) (also simplified). Parsing unknown: 1 as an invalid <declaration> saves time when evaluating @supports to determine if its contents must be applied by the UA, because it would be probably marked as <any-value> (<general-enclosed>), so they do not neet to re-evaluate its support for the <declaration>.

So I propose to make <supports-decl> invalid when the UA does not support its <declaration>, instead of <declaration>.

I do not like making a grammar sensitive to browser support (which it already is with <declaration>), so it would wise to discuss more about it.

  Style sheets <strong>must not</strong> use such a rule and
  processors <strong>must</strong> ignore such a rule (including all of its contents).
+
+ If the UA does not [=support=] the declaration within the parentheses,
+ <<supports-decl>> is invalid.

  : <<supports-decl>>
  ::
- 	The result is true if the UA [=supports=] the declaration within the parentheses.
+ 	The result is true.

  If a processor does not implement, with a usable level of support,
  both the property and the value given,
  then it <strong>must not</strong>
- accept the declaration or claim support for it.
+ claim support for it.