Runtime Color Access Breaks With Material UI v6 CSS Variables Theme

Migrating a Material UI application to the CSS variables theme in v6 via CssVarsProvider introduces a compatibility boundary for runtime color access. The transition changes theme.palette.* values from static color strings to var(--mui-palette-...) references, and the API surface is documented as experimental with defaults that vary between v6 and v7 releases.

The affected feature is runtime color resolution for consumers that cannot interpret CSS custom properties, such as canvas rendering, SVG generation, or third-party chart libraries. While the sx prop and system utilities continue to work because they emit var() references, custom components that read theme.palette.primary.main directly in style objects will silently produce invalid CSS values when the variables theme is active.

Documented guidance points to theme.vars or CSS custom properties, but there is no supported runtime resolver for consumers that need concrete color values. Teams must choose between duplicating palette constants, parsing computed styles, or maintaining a parallel classic theme. Partial adoption compounds the issue: without the provider wrapping the entire application, theme.applyStyles('dark') and colorScheme APIs remain inert, producing inconsistent dark-mode behavior. SSR implementations additionally require suppressHydrationWarning on the html element.

What is the supported strategy for components that require concrete color values at runtime? Is there a recommended pattern for canvas or SVG contexts that avoids duplicating palette definitions or parsing the DOM? How should teams stage the migration when only part of the application is wrapped in CssVarsProvider?