This likely applies somewhat to XFRM too and potentially other add-ons who have replicated our approach.
It is mostly expected.
During uninstall, because it wouldn't really be appropriate to do potentially massive file system operations, we mark the content type's attachments as unassociated.
They're then cleaned up in the same way as other unassociated attachments - the next time the hourly cleanup cron runs. However, only attachments which were created over 24 hours ago.
In your exact reproduction case, because the attachments are new, it would take between 24-25 hours until the attachments are cleaned up.
In a more typical reproduction case, the attachments are less likely to be new, so it would take no more than an hour (the next time the cron runs) before they're cleaned up. It can be triggered sooner than up to one hour if you just run the cron manually.
In an even more typical reproduction case, in the vast majority of cases, this is unlikely to be an issue whatsoever because generally if someone is uninstalling the add-on, they're unlikely to be reinstalling straight after.
In your case when XFMG is being re-installed, the new media items are inserted as expected with new attachments but the relation will most likely pick the first matching record that matches, e.g. content_type = 'xfmg_media' and content_id = 1. It doesn't take into account what the value of the unassociated column is, so it ends up picking the first attachment it finds which is the one that is now unassociated and ignoring the second matching attachment which would be the newest.
This fixes itself automatically when the unassociated attachments are eventually deleted.
Perhaps it would be better to take into account the unassociated state and I'll at least look into that but all things considered this isn't generally an expected scenario.
