Trouble of custom implementations => radical idea: fork MUI v4?

[WilliamKelley]

This is coming from my recent series of PRs (#329, #331, #332, #333, #334, #335) to remove the need for ThemeProvider, it just gets too complex implementing an equivalent wrapper, and for some components it's not even possible because of internal composition (I was in the process of Input which touches InputBase, then Select which needs the same styles, then TextField which inherits from the previous, but also FormLabel, InputLabel, FormGroup, etc. etc. you get it...

Radical idea: since MUI v4 is EOL, we could just fork it and customize everything at the root, instead of wrapping and workarounds...

The bad part is it gives us no clear upgrade path to v5. That could be very bad and actually not worth any trade-off.

The good part is that customization would be simple, and I can take out a ton of extra logic and bloat in most of the core components:

• everything about TouchRipple in ButtonBase (the majority of logic living there)
• modifying internal SwitchBase composition to use ButtonBase instead of IconButton, simplifying levels of redirections
• removing variant and ripple logic from useFormControl
• removing variants of *Input, TextField, etc.
• removing color options
• etc.

It would be seriously custom but seriously reduce size and complexity for itself.