Good easy question.

Of course it may be that the query processing could order the merge conditions in order of specificity. We did that with the pattern matching conditions of Hope+, maybe Haskell inherited that too so it's not obviously out of the question - but I haven't examined the semantics of merge conditions to determine whether there is guaranteed always to be a data-independent specificity-based total order on them, and I can't assert it is possible when I haven't done that analysis. If it is possible and straighforward then doing it would make it possible for people to write much more confusing Merge statements, which doesn't sound like a good thing, but it would also make it possible to tack more specific conditions on at the end and there is a good argument that writing conditions in increasing specificity order (instead of in the reverse order, as required by the SQL Merge statement) improves code readability. So what do people think - woul dthat be a good change to SQL or a bad one?