Comment 3 for bug 775712

> "implementation-dependent" is a long, long way away from "undefined consequences"

Actually, I think in this case, it's a short, short way away from it. Consider this:

Did SBCL, as a project, go out of its way to define this behavior and document it, and is it ready to support the current behavior "in perpetuity"? Did it carefully analyse the situation and decide: "Yes, the correct thing to do is definitely to provide a fresh binding for each iteration of DOLIST, and reuse the same binding for all iteratinos of DOTIMES and LOOP!" ?

Or is the current behavior a mere implementation detail that wasn't explicitly considered and is subject to change? In my view, "This is implementation-defined behavior which this implementation doesn't explicitly define" is about the same thing as "This is undefined behavior."

And it's possible (and allowed) for behaviors specified as undefined to be defined by implementations, so the difference between undefined and implementation-defined is somewhat "philosophical".

> At this moment, DOLIST context is lost, so the compiler cannot warn you about it.

What about something like this?

(BLOCK NIL
  (LET ((#:N-LIST597 '(0 1 2)))
    (TAGBODY
       #:START598
       (UNLESS (ENDP #:N-LIST597)
         (LET* ((#:TMP599 (TRULY-THE (MEMBER 2 1 0) (CAR #:N-LIST597)))
                (I #:TMP599))
           ;; Hypothetical new declaration type
           (DECLARE (ITERATION-VARIABLE DOLIST I))
           (SETQ #:N-LIST597 (CDR #:N-LIST597))
           (TAGBODY (PUSH (LAMBDA () I) LIST)))
         (GO #:START598))))
  (LET ((I NIL))
    (DECLARE (ITERATION-VARIABLE DOLIST I))
    I
    (NREVERSE LIST)))

The fact that it comes from a DOLIST doesn't necessarily have to be recorded, but you get the point. The fact that the required contextual information is *currently* lost doesn't seem like a problem to me at all!