I've tried this with an external image (only url att) and with an image from the media library (id and url atts). Both work well with the pattern I'm using for testing purposes:

<?php
/**
 * Title: demo pattern
 * Slug: twentytwentytwo/demo-pattern
 * Categories: text
 * Block Types: core/paragraph, core/image
 */
?>

<!-- wp:paragraph {"backgroundColor":"pale-cyan-blue"} -->
<p class="has-pale-cyan-blue-background-color has-background">hi rigatonious</p>
<!-- /wp:paragraph -->
<!-- wp:image {"style":{"border":{"width":"18px"}},"className":"is-style-rounded"} -->
<figure class="wp-block-image has-custom-border is-style-rounded"><img src="https://images.unsplash.com/photo-1544005313-94ddf0286df2?ixlib=rb-1.2.1&amp;ixid=MnwxMjA3fDB8MHxzZWFyY2h8NHx8cGVyc29ufGVufDB8fDB8fA%3D%3D&amp;w=1000&amp;q=80" alt="" style="border-width:18px"/></figure>
<!-- /wp:image -->

I've been thinking on situations in which this could break the "transform to pattern" feature. I've found none.

In theory, one use case that could render a failure is this:

• the source block image is an external image (only url att, no id att)
• the target pattern image only has the id attribute

In this case, because of how the transforms to pattern works, the resulting image would have the url of the source image and teh id of the pattern.

In practice, though, I can't see this happening: the pattern would need to provide an ID for the site's media library, which changes from site to site.

I've just tried what happens when an image has a wrong ID. The block appears as invalid:

So, in the very unlikely situation the above can happen, the resulting state is that the user ends up with an image that is invalid and that can self-correct by clicking "Attempt block recovery". I think this is a fairly safe situation.

In practice, though, I can't see this happening: the pattern would need to provide an ID for the site's media library, which changes from site to site.

Exactly