Michał Dudak

@siriwatknp the second option looks the best to me, but it would be inconsistent with what we already have. The first one is OK as well. I'll update the PR.

Good catch. I'll see what I can do about it. You're right that it comes from components that use nested components in their roots (like Button using ButtonBase).

> I think that it could be even better to start without the .Mui-Material classes and equivalent @oliviertassinari according to the [poll results](https://github.com/mui/material-ui/pull/33411#issuecomment-1249280951), if I understand you correctly, what you're...

@oliviertassinari, @siriwatknp, there's another option we can consider - we don't add the product classes (`.Mui-base`, `.Mui-material`, etc.) here. Still, we allow developers to add them if needed (with #34380,...

We discussed this with @oliviertassinari in a meeting. We agreed to use this PR just to make the classes in Base consistent (`.MuiComponentName`), not to add product classes here, and...

The PR has been updated to include the latest agreements. @oliviertassinari, @siriwatknp, it's ready to take another look on, if you'd like.

> Regarding Joy UI's class name, I guess it's outside of the scope of this PR? Yep, this change is only about Base.

Let's discuss the usage of @mui/utils and whether we should import from Utils or Base or any other package separately. I'm going to merge this PR since there are no...

I may have done something differently when testing this locally. It doesn't work on codesandbox indeed.

I remember @eps1lon was in favor of this change when we discussed it. @oliviertassinari, @siriwatknp, @hbjORbj, do you have any opinions on this topic?