Block Render Caching Defeats the Point of Render

To fully describe the issue, the same meta box blocks are producing the same code on different posts that should be displaying different information.

This is due to a recent update in version 3.6.0 where a block that has the same exact json data is cached improperly. The code in question is in /meta-box-aio/vendor/meta-box/mb-blocks/src/Loader.php:101 in the function prepare_render_callback_data.

The problem is if you copy/paste, duplicate or use a block in a pattern, the json data is identical, but the resulting content should be different based on different factors, like the post loaded, or a user is logged in vs not, etc.

Currently, if you view one post and then another post with an identical block, the second post is displaying the content of the first post.

This doesn't happen if you add the block manually since a random id is added at that time, but if you reuse a block in any way (again, copy/paste, duplicate, pattern), the cache conflicts and a bad cache (incorrect post) is returned.

Recommended solutions:

1. Remove the cache as it defeats the point of render in the first place and goes against what core is doing. Rely on page cache to save resources rather than implementing a custom object cache.
2. Allow an override setting, so that the cache is optional dependent on how the block works. Some could be cached in this manner and work correctly, others can't.

To replicate create the simplest block and then create a post, add the block and save. Then copy the block, create a new post, paste the block into the new post and save. Then view post 1 and then post 2. Post 2 will display post 1's id.

block.json

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 3,
	"name": "meta-box/wtr-id",
	"title": "WTR ID",
	"description": "Displays the WTR id.",
	"keywords": [
		"wtr",
		"id"
	],
	"supports": {
		"customClassName": true
	},
	"attributes": {
		"element_type": {
			"enum": [
				"span",
				"div"
			]
		}
	},
	"render": "file:./block.php"
}

Field definitions:

function wtr_id_field_settings( $meta_boxes ) {
	$meta_boxes[] = array(
		'id'     => 'wtr-id',
		'title'  => 'WTR ID Field Content',
		'type'   => 'block',
		'fields' => array(
			array(
				'id'      => 'element_type',
				'name'    => 'Text Element Type',
				'type'    => 'select',
				'options' => array(
					'span' => 'span',
					'div'  => 'div',
				),
			),
		),
	);

	return $meta_boxes;
}
add_filter( 'rwmb_meta_boxes', 'wtr_id_field_settings' );

Render file block.php:

<?php

echo get_the_ID();

The cache is displaying on the front end, the cache is not used in the editor. The code in your plugin is very simple and direct and makes it obvious the cache is not used in the editor but is used everywhere else:
/meta-box-aio/vendor/meta-box/mb-blocks/src/Loader.php:101
`
$is_editor = defined( 'REST_REQUEST' ) && REST_REQUEST && isset( $_GET['context'] ) && $_GET['context'] === 'edit';

// Generate cache key based on block ID and attributes for non-editor requests.
$cache_key = null;
if ( ! $is_editor ) {
$cache_key = 'mbb_render_' . $meta_box->id . '_' . md5( wp_json_encode( $attributes['data'] ?? [] ) );
$cached = wp_cache_get( $cache_key, 'mb-blocks' );
if ( $cached !== false ) {
return $cached;
}
}
`
The cache seems to clear on post save some times and also only has a 5 minute lifespan, but it's long enough to cause all kinds of trouble.

If you publish both posts and then view them subsequently, you will see the issue plainly.