Hi Nathan,
Thanks for your response. That would be an optional workaround, however, it does not address the main issue. Modifying a record, or adding a new record that is buffered by two records that have the same values should "naturally" merge all three records.
The reason I believe that the workaround is not sufficient is because this occurs for many scenarios, not just the scenario above where exact measures are being changed. If you use the create linear events to create an event "A" from measure 0.5 - 2.5 in the scenario above, you will still have a similar "after" table of two records.
Another issue is that many users will be using an attribute set to update multiple events at the same time. To use the workaround you are proposing, they would need to check the adjacent event records for each individual event at the location where they intend to make a change and then make a decision about whether or not they should use the attribute set when they add linear events, or if they should use the merge events widget. This would need to be done for every single edit, greatly reducing the timeliness of editing data and eliminating the benefit of utilizing an attribute set.
Additionally, if that middle red portion were a different route that was reassigned to fill the gap in the blue route, and both routes had the same event value, the events do not merge together.
There appear to be multiple scenarios where a user would expect a full merge to occur based on their edits, but that does not occur.
