Saving to theme ignores patterns defined in PHP

I have a theme which uses templates and template parts. In some of the template parts, the content is pulled in from a PHP pattern, in which e.g. placeholder images are referenced by a PHP function.

For example:

<!-- wp:pattern {"slug":"sht/footer"} /-->

This loads a file (much simplified) with the following content.

<?php

/**
 * Title: Footer
 * Slug: sht/footer
 * Categories: hidden
 * Inserter: no
 */
?>
<!-- wp:group {"className":"c-footer","style":{"spacing":{"blockGap":"0","margin":{"top":"var:preset|spacing|xlarge"}}},"layout":{"type":"default"}} -->
<div class="wp-block-group c-footer" style="margin-top:var(--wp--preset--spacing--xlarge)">
	<!-- wp:pattern {"slug":"sht/footer-logos"} /-->
	<!-- wp:pattern {"slug":"sht/footer-contact"} /-->
</div>
<!-- /wp:group -->

This, in turn, loads more nested patterns, as you can see. This works fine.

However, the site has been online for about a year now, and the client has changed some of the footer content. Saving the current version out from the Site Editor using your plugin overwrites the footer.html file with the content from the editor, including fixed image paths and a fixed website domain. (This was previously output in a dynamic way using PHP functions.)

Is this expected behaviour? Am I expecting too much of the functionality? Do I have to manually go through all of the rewritten template parts and migrate everything back to the PHP patterns by hand? I am not expecting the PHP files to be updated, but I'd appreciate an update on the current best practice for this process. It's a very common one for agency projects.

Start with the Site Editor save flow in the create-block-theme plugin and compare the generated footer.html with the referenced PHP pattern files and nested pattern markup. Reproduce the export with dynamic PHP content, then determine whether preserving PHP patterns is supported; done should be a documented expected workflow or a clearly scoped fix with a regression test.