Maintaining an efficient ordering where you can insert elements "in between" any two other elements in the ordering?
Instead of simple numbering, you could spread the numbers out over a large  (constant sized) range, such as integer minimum and maximums of a CPU integer. Then you can keep putting numbers &quot;in between&quot; by averaging the two surrounding numbers. If the numbers become too crowded (for example you end up with two adjacent integers and there is no number in between), you can do a one-time renumbering of the entire ordering, redistributing the numbers evenly across the range.
Of course, you can run into the limitation that all the numbers within the range of the large constant are used. Firstly, this is not a usually an issue, since the integer-size on a machine is large enough so that if you had more elements it likely wouldn't fit into memory anyway. But if it is an issue, you can simply renumber them with a larger integer-range.
If the input order is not pathological, this method might amortize the renumberings.
Answering queries
A simple integer comparison can answer the query $\left(X \stackrel{?}{&lt;}Y\right)$.
Query time would be very quick ( $\mathcal{O}\left(1\right)$ ) if using machine integers, as it is a simple integer comparison. Using a larger range would require larger integers, and comparison would take $\mathcal{O}\left(\log{|integer|}\right)$.
Insertion
Firstly, you  would maintain the linked list of the ordering, demonstrated in the question. Insertion here, given the nodes to place the new element in between, would be $\mathcal{O}\left(1\right)$.
Labeling the new element would usually be quick $\mathcal{O}\left(1\right)$ because you would calculate the new numeber easily by averaging the surrounding numbers. Occasionally you might run out of numbers &quot;in between&quot;, which would trigger the $\mathcal{O}\left(n\right)$ time renumbering procedure.
Avoiding renumbering
You can use floats instead of integers, so when you get two &quot;adjacent&quot; integers, they can be averaged. Thus you can avoid renumbering when faced with two integer floats: just split them in half. However, eventually the floating point type will run out of accuracy, and two &quot;adacent&quot; floats will not be able to be averaged (the average of the surrounding numbers will probably be equal to one of the surrounding numbers).
You can similarly use a &quot;decimal place&quot; integer, where you maintain two integers for an element; one for the number and one for the decimal. This way, you can avoid renumbering. However, the decimal integer will eventually overflow.
Using a list of integers or bits for each label can entirely avoid the renumbering; this is basically equivalent to using decimal numbers with unlimited length. Comparison would be done lexicographically, and the comparison times will increase to the length of the lists involved. However, this can unbalance the labeling; some labels might require only one integer (no decimal), others might have a list of long length (long decimals). This is a problem, and renumbering can help here too, by redistributing the numbering (here lists of numbers) evenly over a chosen range (range here possibly meaning length of lists) so that after such a renumbering, the lists are all the same length.

This method actually is actually used in this algorithm (implementation,relevant data structure); in the course of the algorithm, an arbitrary ordering must be kept and the author uses integers and renumbering to accomplish this.

Trying to stick to numbers makes your key space somewhat limited. One could use variable length strings instead, using comparison logic &quot;a&quot; &lt; &quot;ab&quot; &lt; &quot;b&quot;. Still two problems remain to be solved
A. Keys could become arbitrarily long
B. Long keys comparison could become costly