Thank you @ajlende!

I thought that for WP_Theme_JSON, we could actually fix the caching issue with a small change to get_blocks_metadata that I proposed here:

diff --git a/src/wp-includes/class-wp-theme-json.php b/src/wp-includes/class-wp-theme-json.php
index 77b77388af2..594ad4c61c7 100644
--- a/src/wp-includes/class-wp-theme-json.php
+++ b/src/wp-includes/class-wp-theme-json.php
@@ -729,14 +729,19 @@ protected static function append_to_selector( $selector, $to_append, $position =
 	 * @return array Block metadata.
 	 */
 	protected static function get_blocks_metadata() {
-		if ( null !== static::$blocks_metadata ) {
-			return static::$blocks_metadata;
-		}
-
-		static::$blocks_metadata = array();
-
 		$registry = WP_Block_Type_Registry::get_instance();
 		$blocks   = $registry->get_all_registered();
+
+		if ( null === static::$blocks_metadata ) {
+			static::$blocks_metadata = array();
+		} else {
+			// Do we have metadata for all currently registered blocks?
+			$blocks = array_diff_key( $blocks, static::$blocks_metadata );
+			if ( count( $blocks ) === 0 ) {
+				return static::$blocks_metadata;
+			}
+		}
+
 		foreach ( $blocks as $block_name => $block_type ) {
 			if (
 				isset( $block_type->supports['__experimentalSelector'] ) &&

This mostly leverages PHP's array_diff_key: It looks at the list of currently registered $blocks and compares its keys (which are block names, e.g. core/heading) to those of the list of blocks metadata -- which are also keyed by block name. It then returns the subset of registered $blocks whose keys aren't in static::$blocks_metadata. If that subset is empty, we return the cached blocks metadata, as we can assume that we have metadata for all registered blocks already.

Otherwise, we add metadata -- for that subset of registered blocks only that doesn't have them yet.

(It was WP_Theme_JSON_Resolver that I've found harder to fix, see the related discussion over at WordPress/wordpress-develop#3359.)

(FWIW, I'm in favor of merging this PR -- I agree with the "minor performance or code quality improvement" rationale 👍 )

Hey, while working on #46579 I realized this PR was not backported to WordPress 6.1. When we land that PR and then backport to WordPress 6.2 everything will be fine, but I wanted to raise in case you think this should be ported for a potential WordPress 6.1.X release.