constraint solving or >-> version of n-queens slow

It seems >->> is simply faster because it forces an enumeration from left to right.
:- block tbij(,?,?,?,?,?), tbij(?,?,,?,?,?).
tbij([],_,0,Dom,Ran,WF) :- empty_set_wf(Dom,WF),empty_set_wf(Ran,WF).
tbij([(X,Y)|T],SoFar,s(Card),Dom,Ran,WF) :- % prints(tbij(X,Y,T,s(Card))),
%not_element_of(X,SoFar), necessary ??
remove_element_wf(X,Dom,Dom2,WF), % instead of setup_domain, we could remove first element if X,Y are free
remove_element_wf(Y,Ran,Ran2,WF), % this forces an enumeration from left-to-right, as Ran is only set when previous element was enumerated
add_new_element_wf(Y,SoFar,SoFar2,WF),
not_element_of_wf(Y,SoFar,WF),
%prints(chooseY(Y,forx(X),Ran,Ran2,sofar(SoFar))), portray_waitflags(WF),nl,

Commit d67f6f8e1ac1038df767c2b655001dafd14d7af1 lead to a reverse in the FD variable list and means variables are prioritised backwards from before; meaning that here enumeration starts on column 12.
It is easer to solve the problem going from left to right here, the last column has no additional constraint attached to it; it can be freely chosen if the others are fixed.

It seems related to enumeration order.
With -p RANDOMISE_ENUMERATION_ORDER TRUE it is generally much much faster.
The same problem with >->> is also much faster.

This is actually not the n-Queens Problem, but a Variation thereof (generated by a typo).