I just saw an interesting edge case: Aarne Granlund (@aarnegranlund.eurosky.social)
It says something about blobs when I try to change my header picture. I like Eurosky, it’s not a biggie!
As of writing this, their profile picture blob seems to be missing, so since editing their header picture doesn’t touch that blob reference, the updated profile record is rejected.
If both were missing, the user would likely be stuck in that case, as they can only be edited or removed individually in the app.
In my opinion, Blob Lifecycle - AT Protocol Docs - AT Protocol should specify that when an existing record is updated or replaced (and the one doing so is permitted to read it), blobs that are already present in the existing record should cause the respective blob presence checks to be skipped.
This would make apps across the ecosystem behave more gracefully without fraught overrides (and allow non-destructive edits where still-missing blobs may be restored later), and the check would still prevent the creation of new references to non-existent blobs reliably.