Hi, I didn’t had much spare time in the last weeks, but I kept thinking about the idea of representing repetitive dives on libdivecomputer Initially I wrote a simple spreadsheets to summarize the pros and cons of possible approaches . Colors represents the “severity” of a drawback or of an impact and are my guesses. We may use it to confront ideas. Generally speaking I think that the API should really include a way to pass free-form data to the app, while right now everything is codified in the "least common multiple" of all the DC capabilities. It may seems a weird thing to do, but consider that each dc may have specific information which the user (who chooses and bought that DC) may want to be represented on the profile. I am thinking about alarms and statistics, and also the whole “subdive” stuff. It could be a good idea to introduce some kind of USER_EVENT (or USER_SAMPLE) with name, type (int, float, bool, string) and value fields. Parsers should use the USER_EVENT to report info which the app may choose to skip, draw as it is or elaborate. Then we may define policies on such events. Such that 'alarms name shall start with "AL_'" or similar to hint the apps. This would be, in my opinion, a progressive and low-impact way to improve flexibility of the API. Referring to the attached table, such change would allow for a simple a straight forward implementation of the workaround for the drawbacks of the “Merge Subdives” approach or for the whole “report session and dives in an unstructured way” stuff. Let me know what do you think about it. G