One solution here could be to explicitly detect and ignore known function syntaxes, as it appears to be a very finite and set concrete list:

• font-format()
• font-tech()
• selector()

Doing it this way and not arbitrarily matching a string(…) pattern would also avoid matching for all strings where some others are valid non-function syntax (e.g. and|or|not).

UPDATE: In my related PR #13596, I opted to support the hyphen character in supports checks, which appears to fix the issue and resolve the cases you mentioned with one exception (details below) and add support for custom properties the same way we currently support native ones.

• supports-[display] ➞ @supports (display: var(--tw)) ✅
• supports-[--test] ➞ @supports (--test: var(--tw)) ✅

Thoughts for the future — it could be helpful to set up extensions to the supports rule to support each of the function syntaxes in the future, e.g.:

• supports-font-format-[opentype]
• supports-font-selector-[h2>p]

⚠️ This still wouldn't account for the present use case of using them inline, which is the immediate need

@adamwathan I opened PR #13596, which should resolve this issue. It does not fix the supports-[content:"("]:grid test you mentioned, but as that does not appear to be directly related to the supports-variant effort and is more related to the parser itself, I would prefer to handle that case in a separate PR.

You can see here that this was an issue before: https://play.tailwindcss.com/M7FOiImx9l

I confirmed that example (supports-[content:"("]:grid) doesn't reach the test, so it would appear to be filtered out by the parser. supports-[content:"test"]:grid works, indicating that the parenthesis is the other example is problematic. I'll take a deeper look at how the parser handles quoted strings inside arbitrary values and see if something is missing there.

Reopening so we fix this in v3 as well.

@adamwathan #13605 should fix this for v3