It's worth remembering that this is undefined behavior. It is usually safe to start defining behavior in undefined cases as they should be, by definition, backwards compatible.
To be honest, this is not an aspect of Iterate that I was aware of. It is a bit surprising that this is undefined behavior. Gabor's examples are a bit theoretical, but if my understanding is correct, the following functions have undefined behavior.
(defun split-on1 (obj list &key (test 'eql))
(iter (for (x . list-b) :on list)
(collect x :into list-a)
(until (funcall test obj x))
(finally (return (list list-a list-b)))))
...or, if you prefer that the element goes on the second list,...
(defun split-on2 (obj list &key (test 'eql))
(iter (for (x . list-b) :on list)
(until (funcall test obj x))
(collect x :into list-a)
(finally (return (list list-a (cons x list-b))))))
I suppose that the specification states that both of these are undefined (due to the usage of x in on-split1 and x and rest in on-split2), though some testing seems to suggest that they work. Seems like defining the bindings would be a step in the right direction. Am I missing something?