The closest to that in CSS is color-contrast() which isn't in any browser yet. There's a lot CSS still can't do.
The actual interpolation/processing would still be outside of the browser.
IIRC, the normative framework for this is pretty new, and I don't now the rules about function names.
The pain with SASS et al is real though.
Most frequent offenders in my experience:
- the max() function
- the division symbol occuring in values of native properties such as grid-column or aspect-ratio
Both have been deprecated in newer versions, but it is impossible to automatically fix this unless you know that all of your (S)CSS was written before these features were introduced.
So if a function in CSS is func(), then a custom author-defined function will always be --func() and it should be parsed and safely ignored by browsers or things that don't understand it, but still present in your CSS for tools to read and operate on so you can define custom features and use them within standard CSS no matter how or where you are providing the support (you could process some things in advance like a preprocessor, or it might be a feature that only makes sense to support client-side in a browser or at the time the CSS is being evaluated).
Totally makes sense and fits well with CSS custom properties.
While naming rules as syntax might seem smelly when it exceeds banning keywords as identifiers, I find this to be a sensible and well-thought-out rule, similar to the Custom Element dash-tag-name rule (notwithstanding other issues with the Web Component standard)
It's KISS and does it's best to make a good tradeoff regarding forwards-compatibility.