What problem does this address?

For a long time WordPress did not revise meta, so we came up with a bit of a "shim" to have fields that call for meta to resolve from the parent (the published post) so that null values were not returned, but rather the published post's values were returned.

Now that meta revisions are supported by WordPress core, it would be good to revisit our shim (see: https://github.com/wp-graphql/wp-graphql/blob/develop/src/Utils/Preview.php#L7-L57).

What is your proposed solution?

Currently we can use this filter to tell WPGraphQL to use the revision meta instead of the parent (published post) meta.

add_filter( 'graphql_resolve_revision_meta_from_parent', function( $default, $object_id, $meta_key, $meta_value ) {
	if ( 'footnotes' === $meta_key ) {
		return false;
	}
}, 10, 4);

I would like to use the meta registry to automate this, so that any meta field that has opted-in to revisions would automatically work without users having to implement a filter manually like this.

What alternatives have you considered?

Allowing users to continue explicitly opt-in/out using the graphql_resolve_revision_meta_from_parent filter.

Additional Context

related:

• Preview not working with Published Pages WordPress/gutenberg#16006 (comment)
• see: Preview not working with Published Pages WordPress/gutenberg#16006 (comment)