Repository: material-ui
Issue: Inventory of how to customize the global theme in v5 
Labels: docs,discussion,package: system

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current docs

The docs for v5 are really good.  In the [theme customization section](https://mui.com/customization/how-to-customize/) I was taking inventory of how to customize the theme used throughout the app.  While doing so, I was not able to fully understand the capability in one or two spots.  If it's not just my missing something, I thought it might be worthwhile to clarify in the docs accordingly.

## Scope of how to create a theme that is inherently responsive

Here is the summary of how the "theme" as "function that generates a theme", we have the following options enabled by the `mui` `createTheme` engineering:  

`createTheme` takes the following value that has "built-in" capacity to respond:

```js
components: {
    MuiComponent: {
        defaultProps: {
            'mui-propName': value
        },
        styleOverrides: { 
            'mui-slot': Object  // { jsCssProps } 
                      | Function ({ ownerState, theme }) => {..} // return { jsCssProps }
                      | sx({ sxObject }) // requires experimental_sx, mui uses @emotion to interpret
                      | `css` // js string literal that complies with css syntax; access to global theme?
        },
        variants : [
            {
                props: { variant: `nameOfVariant`, ...otherMuiProps }, // ~v4 default props, variant is required
                style: { keyValue }, // css? or jsCss?; does the value in { key:value } has access to global theme?
            }
        ]
    }
}
```

The above accomplishes: 

<details>
<summary>
"dynamic" comes from changing `className`
</summary>

```js
   mui default theme 
-> refs that match mui components/slots present in our theme 
-> component specific style
```

The styles are applied when the application of the css selector expression returns the component/node being rendered.  The dynamics comes from the ability to change the `className` values ("for free" when the browser dynamically switches `pseudo-element`s).

</details>

Efficiently specify different versions of related components by way of code reuse that that comes with using a function and parameter combination.

## The open questions

1. As I ask the question, I suspect the answer is obvious, but I wanted to clarify.  Access the `theme` value:
	* When `createTheme` encounters `styleOverrides: String` does it create a closure with access to the `theme` value? So, can we set the value of `mui-slot`: `color: ${theme.palette.primary.main}`?
	* Similarly, when `createTheme` encounters `variants`, does it interpret the `style` value in a closure with access to the `theme` value?

2. Given that the place to call `createTheme` is at the root of the app by way of 
```js
<ThemeProvider theme={createTheme(myInherentlyDynamicTheme)}><App /></ThemeProvider>`
```
in the event I am using `CssBaseline`, what is the advantage of creating `myInherentlyDynamicTheme` using the `CssBaseline` overrides I saw documented?

3. Given the now *defacto* demand for a UI that toggles between light and dark themes, from within the `App`:
	* I can read the `theme` value using the `useTheme()` hook from `'@mui/material/styles'`, but
	* there is no-way to create a new theme to be applied to the `App` globally; in other words, the question is what prevents `'@mui/material/styles'` from providing access to a `setTheme` function?
	* the "work-around" is to wrap the `<ThemeProvider />` in a context with a theme that depends on the extra context to create another layer of responsiveness.  Yes?

## Is there no way to change `ThemeProvider`'s  internal ref to theme?

If not, this inability to call a `setTheme` directly on `ThemeProvider` limits the scope of the dynamics of the theme. This limit is the reason for documented approach where we roll-our-own `Context` that hosts `[mode, setMode]`? (a context that is a parent to `ThemeProvider`).  Is this right?

Thank you in advance to confirming/clarifying.