https://drafts.csswg.org/css-color-5/#color-syntax
https://webkit.org/blog/16929/contrast-color/
color-contrast()

note

This set is used by color-named.

e.g. hsla(from infotext h s l)
ref https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_colors/Relative_colors

Is it correct that we actually want to check if background is intended as a <color> or as some unrelated argument to a function?

a {
  /* background as color */
  color: rgb(from background r g b);
}

a {
  /* background as color */
  color: var(--foo, background);
}

a {
  /* background as color */
  color: rgb(from var(--foo, background) r g b);
}

a {
  /* background as color */
  color: rgb(from if(style(--foo: bar): background; else: white) r g b);
}

a {
  /* background as a random keyword */
  color: if(style(--foo: background): red; else: white);
}

a {
  /* background as a random keyword */
  color: --custom-function(background);
}

Demo

This would also be easier to keep track of with the state feature of @csstools/css-parser-algorithms.

When entering a function like var(), if(), rgb(), ccolor-mix(), contrast-color(), ... is encountered the checks for values like background would run.

When entering unrelated functions like style(), --custom-function(), ... the checks would skip.

Out of the properties/values supported only the color functions are relevant.
Also the user would expect the rule to pick the deprecated keyword within those functions.

e.g.
calc-size doesn't support intrinsic AFAIK so it doesn't need an exception because it would be invalid in the first place. Now the actual wording in the specification is not really precise:

The production matches any intrinsic size keywords allowed in the context.

so I might be wrong.

Granted, it would be much simpler to ignore all functions.

off topic
l132

Ignored keywords may erroneously not be ignored in some cases.
i.e. it should be done inside parsedValue.walk((node) => { … }); too
It won't be fixed in this PR though.