All the runScheduledAction complexity seems to be redundant

From the https://github.com/haskell-distributed/network-transport-tcp/commit/3855e91dcad7381f6626fc47adb8f4c9c60d5279:

Simply doing

thingToSend <- modifyMVar (....)
send thingToSend

is not good enough, because now if we have to threads doing the above the sends
may be done in the wrong order.

Before https://github.com/haskell-distributed/network-transport-tcp/commit/876a3dc94e516c9ec60ea8b0a65ea3f13b8c1f27 it was true. But after sendOn was protected with MVar it seems that it became redundant, because, as @simonmar states in his book:

if a thread T is blocked in takeMVar and there are regular putMVar operations on the same MVar, it is guaranteed that at some point thread T’s takeMVar will return. In GHC, this guarantee is implemented by keeping blocked threads in a FIFO queue attached to the MVar...

In other words, the first thread called sendOn and blocked on MVar will be served first when the MVar will be available (if I understood correctly the book). So it seems that "simply doing" approach mentioned in the beginning will just do. No?

CC @edsko

Start by comparing the referenced commits 3855e91 and 876a3dc, then trace runScheduledAction and sendOn to understand the ordering guarantees around the MVar. Determine whether the scheduling complexity is redundant and document a concrete, testable scope before changing it.