Hi,
Disclaimer: I am not a lawyer. Nor do I claim to understand all this stuff.
The enforcement of sequential ordering is sort of baked into monads; the haskell (read: do-notation) way of combining monadic computations is using bind (i.e. in the "fancy list of instructions with a way to bind results"). This is only for the structure of the computation, though. Every monadic computation is still a pure function, so in the end the RTS, well, executes parts of those at a time, just as pure functions.
The ordering guarantee that more corresponds to imperative programming is most obvious (to me) with ST, IO, and State; data dependencies ensure that things "later" in the monadic chain cannot be executed until everything "before". But those effects all involve (mutable) state. Monadic chaining, i.e. combining effectful computations, is separate from the concept of mutable state, etc. It seems more like just an algebra for effects.
If you're talking about marked monads as in those with extra type information or phantom params, like when used in tandem with the rank-2 type trick (used in ST, region-based IO, etc.), I think that's a little different, or at least beyond what monads are. Those were created to handle things like guaranteeing that state is only modified single-threadedly (ST), or to ensure that you can't do things like forget to close a handle or leak a ref to a closed one (regions).
I think Free monads and (Kiselyov's) Eff monad are still different. They still appeal to the "monads as sequence of instructions" view, but uh, especially with the Eff monad, they're pretty fancy. As in at least personally, for "normal" programming, I haven't felt the need to delve into them.
I think the important upshot is: what are you working on? Do monadic computations model what you want to do naturally? If they do, do you need something stronger than what they provide? It's hard to answer the latter questions without answering the first.
Sorry for rambling,
toz