bug#67008: 30.0.50; Multiple major mode parents

[Mattias Engdegård]

> Yes we strictly obey the vertical edges (and call `error-function` when
> that's not an option) and we use the horizontal edges when there's
> a choice.

Yes, but `merge-ordered-lists` doesn't distinguish between vertical and 
horizontal edges in any way, does it? We only get a consistent (monotonic) 
result if the input is ordered correctly.

In that respect `merge-ordered-lists` is just half an algorithm. We could add 
the other half but presumably this wouldn't be a good fit in places where the 
function is currently used?

The other half might be something like: compute the linear order for each 
parent in sequence, then add the partial order (NODE PARENT1...PARENTn).

The documentation text

> The order of the (sub)lists determines the final order in those cases where
> the order within the sublists does not impose a unique choice.
> Equality of elements is tested with `eql'.

could perhaps be written more precisely to say that when the constraints do not 
impose a relative order between elements (not sublists), they are ordered by 
their occurrence in the input.

`merge-ordered-lists` should also have the left-to-right property that

(merge-ordered-lists (append X Y))
= (merge-ordered-lists (cons (merge-ordered-lists X) Y))

although I haven't verified this.