Omitting the third parameter here prevents error when a high-level PHP template exists in a hierarchy - #37236 (comment).

I don't think resolving to PHP templates is helpful for Site Editor. So instead, we fall back to the closest block template.

Can we put the PHP into lib/compat? wordpress-5.9 if we know it will be backported or wordpress-6.0 otherwise.

I think this should be internal function/logic that lives in the site-editor.php file, but we can use compat dir for the plugin.

Done :) I'm not sure if it's the correct file, but I couldn't find anything specific for the site editor.

Why do we want to mark it as experimental? Maybe we should mark it as internal instead?

We don't have an internal prefix. Generally __unstable is for things we know we'll never make public.

I wonder if we could just do the redirection on server-side instead, so we don't need to do anything on the client side (except for exception handling I guess).

You can comment out this line to test the warning when the method cannot resolve the template.

I guess we don't need this to be an async function anymore?

It looks like whenever we find a template with this function, we are redirecting.

Is there a case where the template this function returns is the same as the template the editor would initially resolve in the first place, causing the redirect to be unnecessary?

Is there a case where the template this function returns is the same as the template the editor would initially resolve in the first place, causing the redirect to be unnecessary?

I don't think so. Site Editor needs these query args to resolve the template.