Gutenberg “Block rendered as empty.” using Frontend Admin Form block

I recently updated from 3.28.32 to 3.29.3 and all my forms failed to load and showed as “Block rendered as empty.” when looking at them on the page editor.
I went through a few different versions and found that the change that caused this was introduced in version 3.29.1 (so 3.28.36 being the last version before the problem starts).

I believe I have identified why it has happened.
I was also able to reproduce the issue in WordPress Playground with WP Engine’s Advanced Custom Fields plugin as the only other installed plugin.
Steps:

1. Install Advanced Custom Fields
2. Install Frontend Admin
3. Create a Form using Frontend Admin
4. Add that form to a page using the Frontend Admin Form block in the Gutenberg editor.

Result:
The form shows as “Block rendered as empty.” on the editor page, and doesn’t show at all on the actual page.

The issue appears to be in acf-frontend-form-element/trunk/main/gutenberg/blocks/form.php in the pre_block_render() function.
The issue starts with the form when added as a block is something like this:
<!-- wp:acf-frontend/form {"formID":1453} /-->

Meaning that when we get to this line …
if( empty( $attrs['form_settings'] )) return $block_content;

… we end up in trouble because there is no form_settings, all we have is formID.

So:

• $fea_form is never set
• render() receives no form
• $content is empty
• Block renders nothing

In addition (and perhaps I should’ve mentioned this first) there’s this line further up in the same function:
if( 'frontend-admin/form' == $block['blockName'] ){

However, the name of the block isn’t frontend-admin/form it’s acf-frontend/form. Meaning that we don’t even get as far as the missing form_settings.

I had some luck making some changes in that area that allowed the forms to load.

if( 'frontend-admin/form' == $block['blockName'] || 'acf-frontend/form' == $block['blockName'] ){

    $form_display = $fea_instance->form_display;
        if( ! $fea_form ){

            $attrs = $block['attrs'];
            $fea_current_post_id = $attrs['template_id'] ?? $wp_query->get_queried_object_id();

            //if( empty( $attrs['form_settings'] )) return $block_content;               

            if( empty( $attrs['form_settings'] ) && ! empty( $attrs['formID'] ) ) {
                $form = $form_display->get_form( $attrs['formID'] );
                if( $form ){
                    ob_start();
                    $form_display->render_form( $form );
                    return ob_get_clean();
                }
                return $block_content;
            }

https://www.diffchecker.com/1r9WWYpt/

This only seems to affect the forms added using the block. Forms that use the shortcode seem to follow a different path and aren’t broken in the same way.
I hope this information is enough to help you see the issue and hopefully point in you in a useful direction for resolving it, apologies if my findings turn out to be a red herring.
Also, I expect in now way is what I discovered “fixed” the problem to be a true an complete fix, I just honed in on the one specific issue I was seeing at the time and trying to figure out why that one instance had occurred. I can imagine that an actual fix might look quite different.
Diolch / Thanks.