If you have impossible ordering constraints (A before B, but B before A), it's a mistake regardless of how they are represented.
Of the three representations in the original posts, the third one is by far the most appropriate one because it represents an order relationship correctly; in particular, new "effects" can be added anywhere in the dependency graph, without running into trouble with missing gaps between "layers" or "priorities".
It isn't awful; realistically, a few dependencies imply a node's position with respect to all nodes that matter. For example, many different attack types, with various precedences among themselves, can be specified to happen before explosion rendering; then if you say that the two "final" steps of creating debris objects and swapping in damaged sprites and models take place after explosions, they automatically take place after all attacks too.
The actual game engine should probably process a list of "pass" objects in sequence, but turning a direct acyclic graph of precedences into a processing order is a computer's job; avoid unneeded bookkeeping for game content authors.