Issues with clone fields using prefixes

We have until very recently been using a single field group called global_image to clone into other field groups as a way of having consistent field names/types for responsive images. This has worked for a couple years without issue where we reference the field name of the field using the clone, and inside the response it contains a nested global_image array for us to work with.

An example would be creating a field called my_image in a template field group which clones global_image as a group with prefixed field names checked. In our code, we would call $my_image = get_field('my_image') and then operate on $my_image['global_image'] as needed.

When looking at the wp_postmeta table I can see instances of fields created as expected:

| post_id | meta_key                                          | meta_value          |
| ------- | ------------------------------------------------- | ------------------- |
| 10043   | recommendation_image_global_image                 | 10414               |
| 10043   | _recommendation_image_global_image                | field_5a81cd534f030 |
| 10043   | recommendation_image_global_include_retina_image  | 0                   |
| 10043   | _recommendation_image_global_include_retina_image | field_5a81cd954f032 |
| 10043   | recommendation_image_global_disable_lazy_load     | 0                   |
| 10043   | _recommendation_image_global_disable_lazy_load    | field_5b242ecf48e70 |
| 10043   | recommendation_image                              |                     |
| 10043   | _recommendation_image                             | field_5be4c5730cd6b |
| 101083  | recommendation_image_global_image                 | 101088              |
| 101083  | _recommendation_image_global_image                | field_5a81cd534f030 |
| 101083  | recommendation_image_global_include_retina_image  | 0                   |
| 101083  | _recommendation_image_global_include_retina_image | field_5a81cd954f032 |
| 101083  | recommendation_image_global_disable_lazy_load     | 0                   |
| 101083  | _recommendation_image_global_disable_lazy_load    | field_5b242ecf48e70 |
| 101083  | recommendation_image_global_retina_image          | 101084              |
| 101083  | _recommendation_image_global_retina_image         | field_5a81cd664f031 |

In this case, recommendation_image is the field doing the cloning, and _recommendation_image stores the reference to the clone as I'd expect. When creating a new post of the same post type and using identical content, no values for recommendation_image or _recommendation_image are created in the table.

I am able to access the image as the prefixed field recommendation_image_global_image, but previously that wasn't necessary. Has anything knowingly changed in the last few versions? Was this an unintended hack that we were using without realising?

We are using ACF Pro 5.8.12 btw.

Start by reproducing the clone-field behavior in ACF Pro 5.8.12 with a field such as recommendation_image cloning global_image with prefixed names enabled. Inspect get_field('my_image') and the corresponding wp_postmeta entries, then determine whether the missing nested value for a new post is an intended behavior change or a bug.