A DAG is a Directed Acyclic Graph, basically the set of logical elements and connections that describe your scene (it falls under the process model category the way it’s used in 3D scene graphing).
It’s the same model maya is based on and pretty much any 3D app of a certain magnitude out there that I know something about the internals of.
Most of the time the graph will do just fine, and priority is a non-issue (as it’s determined by the graph pull, not arbitrarily). Occasionally dependency cycles can be created, and a DAG by design can’t solve them, so to break them interrupts and additional directors need to be added to break them, which can be user interaction and so on.
Priority in a straight A -> B -> A cycle with two elements, the most common cycle that’s useful but tough to break, will simply not work.
It’s usually better to address those cycles differently, since the cases where you might want a cycle like that to be evaluated (say bidirectional constraints), simple priority simply breaks it makes it an A -> B or a B -> A eval all the time anyway, which you could do yourself in a cleaner fashion by simply removing one of the two constraints.
In some rarer cases explicit priority however can help, and for that you only have some involved technical workarounds in XSI (forcing something to always evaluate and/or placing a key to always force a pull and so on), but again, it’s a patch on something that ideally the underlying graph management should be good at by default.
Still, the subset of cases is pretty limited, and most of the times if you can’t fix it with an expression or a key in the right place, chances are priority won’t help either.
And probably more important, what evaluation issues preoccupy you so much that you’d like priority control to fix them?
