Ooooh, this is a tricky one. I know exactly what is happening.
So, when you add a list to a schedule, it naturally maintains the binding to that list. You're not actually adding ABCD into it. You're adding "the contents of this list".
Now, with just the single schedule, if you go in and remove AB from it, you're not changing the contents of the list - that wouldn't make sense. Instead, you're putting a "mark" over it, which basically says "include the contents of this list, but keep AB out".
So that's what is happening here - the merge system always takes one of the schedules and makes it the primary schedule - that's the one for retaining the settings.
So schedule 1 has those terms in it, marked as DO NOT USE (so the link to the list can be maintained)
Schedule 2 (secondary) gets added to it.
However, the system does not have a sense of "this schedule has two copies of AB in it" (in your example). The database table that contains the list of terms (extracted from the lists) has one entry for each unique term. It's still holding onto the "DO NOT USE" marker from schedule 1, since it is considered the primary table.
I think the best way to approach this (but I'll need to see if the code makes this doable is to, at the point of merge, see if any of the DO NOT USE terms are present in one of the secondary schedules. If so, then remove that marker.
