What problem does this address?

Several places (e.g. #45372, #45679, #45882) now check for the WP_DEBUG constant to decide whether to use WP_Object_Cache to cache expensive logic around theme.json parsing etc. It is still unclear whether that is the best approach, but most importantly, as this becomes more and more spread out, we should bring that into a single dedicated function. This function can then be used in all of these places, so that we can focus the conversation on the exact approach (even potential changes over the next few weeks) on just that function and not tons of other PRs.

Being able to bypass cache is crucial in these situations for theme developers while they are developing a theme. It is probably almost never relevant in production; e.g. when a theme is updated, we can manually invalidate cache anyway as that is detectable within WordPress. The problem is that direct file modifications e.g. during theme development are not detectable so we cannot invalidate cache reliably for that. To provide a good theme developer experience, we should therefore allow bypassing these specific caches.

What is your proposed solution?

• Introduce a function e.g. wp_theme_cache_enabled()
• Use either WP_DEBUG or in_array( wp_get_environment_type(), array( 'local', 'development' ), true ) for the baseline value. I would now lean towards the latter, as this is less about debugging than it is about working in a development environment (as you are developing a theme, that's when this is most relevant).
• Include a filter e.g. wp_theme_cache_enabled to allow for this to be modified specifically or at runtime.
• Use that function in all the above code instead of the "manual" WP_DEBUG checks, similar for any future code may add more use of WP_Object_Cache around theme related logic.

Let's discuss the exact logic within the function; but I think the overall function approach to have this centralized would definitely be a big plus already.

cc @mmtr @oandregal @spacedmonkey