As a bizarre edge case, I will add an additional way that the macOS (not iOS but have not tested the iOS for this) can group burst photos.
It's widely reported that a shared BurstUUID in the EXIF header identifies members of an iPhone burst. Because of a bug in the way Photos (Monterey, Ventura) handles Bursts imported from Aperture, I used Exiftool to remove all MakerNotes containing a burst ID across an Aperture test library using:
exiftool -r -overwrite_original -P -progress -MakerNotes= -if '$BurstUUID ne "" ' /Users/jfaughnan/Documents/Upcoming\ Events/Aperture\ Migration\ Project/Burst\ Bug/TestSuite.aplibrary
This reported 8 image files belonging to a single burst (4 masters, 4 previews) were updated. On inspection, the MakerNotes were removed.
Despite this when converted to Photos the Burst was recreated (alas, still with the bug). When I exported the original and preview the MakerNote(s) were indeed gone. So how the heck did Photos create the burst even in the absence of an EXIF MakerNotes.BurstUUID?
I don't know, but there's a clue that whatever it does is unique to the Aperture import process—and is probably a bug in the conversion process.
The clue is when I use PowerPhotos to convert the same Aperture Library no Bursts are created. I don't know the cause of the resurrected (pseudo) bursts, but I'm confident it isn't due to something in the images themselves. I think even though Aperture doesn't use the BurstUUID that is somewhere that's being cached, perhaps in an Aperture cache built from EXIF headers. I suspect Photos is using something like that. (However, rebuilding the Photos database does not remove the Bursts.)
I must leave this as a mystery. BurstUUID in the EXIF header does define a Burst. In the case of Aperture conversion by Photos however, Burst information can be passed by an alternate unknown route.