The problem is not necessarily that the comparison is not transitive: that is the difference between a partial order and a complete order (and SORT isn’t required to maintain a partial order). The predicate itself could have that problem.

The problem I was referring to is that two elements, let’s call them A and B, should be in the same order every time the sort algorithm checks them. If the key values of A and B jump around at random, what is the sort supposed to assume? The comparison function is not well-defined at all, not just with respect to transitivity.

Now, it may be that an efficient sort algorithm does not often compare the same elements pairwise; however, the problem is not restricted to pairs of elements. Consider just the element A. The key function ranges from 0 to 1.0 (exclusive); 0 is interpreted to mean “I should be at the very beginning”, 0.999… interpreted to mean “I should be at the very end.”

Any individual element is going to be changing its stated destination every time it is checked. A particular random order, however, is just *one* order. The random seed should pick one order out of the n! possible orders, with equal likelihood, then *stick to* that order. Instead this algorithm jumps around between orders, giving mixed messages to the sort algorithm. It will be hard to predict the outcome of the sort, but also unlikely to guarantee the uniform distribution among the n! outcomes that a random shuffle desires.

(define (shuffle x)
(do ((v (list->vector x)) (n (length x) (- n 1)))
((zero? n) (vector->list v))
(let* ((r (random n)) (t (vector-ref v r)))
(vector-set! v r (vector-ref v (- n 1)))
(vector-set! v (- n 1) t))))

I agree with Joseph that the algorithm is flawed. The problem is that the comparison procedure isn’t transitive: it is possible that a<b and b<c does not imply a<c. Depending on the underlying sort algorithm, bad things may happen, and it is possible that the sort will never terminate. Worse, it is unlikely given this method that all permutations of the input list are not equally likely in the shuffled output, which could be a problem depending on how the shuffle is used (you wouldn’t want your poker buddies to accuse you of stacking the deck — it could be hazardous to your health).

I agree with Joseph that the algorithm is flawed. The problem is that the comparison procedure isn’t transitive: it is possible that a<b and b<c does not imply avector x)) (n (length x) (- n 1)))
((zero? n) (vector->list v))
(let* ((r (random n)) (t (vector-ref v r)))
(vector-set! v r (vector-ref v (- n 1)))
(vector-set! v (- n 1) t))))

With SBCL and your function, I get these results:
;; (3 1 2): 25
;; (3 2 1): 25
;; (1 2 3): 17
;; (2 1 3): 17
;; (1 3 2): 8
;; (2 3 1): 8

A nice and simple perfect shuffle is:
(defun better-shuffle (seq)
(let ((tagged (mapcar (lambda (x) (cons (random 1.0) x)) seq)))
(mapcar ‘cdr (sort tagged #’> :key ‘car))))

(defun seqrnd (seq)
seq)

If the key and predicate always return, then the sorting operation will always terminate, producing a sequence containing the same elements as sequence (that is, the result is a permutation of sequence). This is guaranteed even if the predicate does not really consistently represent a total order (in which case the elements will be scrambled in some unpredictable way, but no element will be lost). If the key consistently returns meaningful keys, and the predicate does reflect some total ordering criterion on those keys, then the elements of the sorted-sequence will be properly sorted according to that ordering.

Your wording is rather hazy, so I don’t know what exactly you’re concerned with, but for me it suffices that the sort will terminate after having shuffled the elements.