Okay, but do you agree with me that the three sorts are stable?
I didn't care enough to analyze the implementations for sorting stability. I just verified that for all input sequences I generate, the results are stable. So, if you have done the analysis, I'll take your word for it.
That does not mean the entire top-down merge sort approach is inefficient.
I've shown that when combined with logic to detect sorted runs, a top-down sorted-scanning merge sort performs at least as well as the sorted-scanning bottom-up merge sort does, for some input linked list types. (It's a specific level of randomness/sortedness, and probably quite CPU dependent.)
This means that even in theory, your initial statement, "top down merge sort is inefficient", is clearly incorrect.
My own original opinion, "In my opinion, top down merge sort has two main purposes: one, as a learning tool (linked lists, recursion); two, as a basis for linked list sorting variants where the list is known to be mostly sorted already." has changed very little based on these revelations, to "In my opinion, top down merge sort has two main purposes: one, as a learning tool (linked lists, recursion); two, as a basis for linked list sort variants that exploit known randomness/sortedness properties of the list."
As I only use merge sort for linked lists, I don't really have any input on that. So, I'll bow out here, if you don't mind.