Interesting, it's seems that we didn't use them in the past. What should we do going forward?

My thinking was, if there are more styles, especially with multiple keys to style a component, styled() looked like the better replacement (I just replaced the keys in the classes with the classes selectors). For trivial, one line changes I used the sx prop.

I like the concept of being able to trust already defined class names instead of typing and making a mistake on it.

It looks interesting to use the same technique that is already used in the creation of the component.

My point was exactly on what @vicasas, the use of the classes object. No real preferences. I like how a plain string is YOLO and often good enough, but I also understand how having a JS object with IntelliSense that describe what each key is for can also help.

Interesting, for another example I remember that I used another form that perhaps should be discussed.

https://github.com/mui-org/material-ui/blob/58c7e708a419bc8895774e964b8ef00b55d045ac/docs/src/pages/components/cards/RecipeReviewCard.tsx#L23

I think it is a bit of a different use-case, but I see your point. I would say that for the pseudo states, we should always rely on the pseudo classes, as we do with the core components, as sometimes it would be impossible to override some css rules if we don't bump the specificity when overriding.

For example, for the disabled state, the core components are defining the styles with:

'&.Mui-disabled': { ... },

If we don't bump the specificity in the overrides, we won't be able to override.