use of minibuffer in interactive spec code

[Drew Adams]

I don't know if this is a bug or a bug fix. I would like to get some info about
it, if possible, to understand better. The behavior in this respect is new in
Emacs 23.2. It changed apparently sometime after this build:

GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2009-01-15 on LENNART-69DE564

I have this command, which is bound to a key during minibuffer completion in a
couple of cases:

(defun foo (dir)
  (interactive
   (list (read-directory-name
          "Dir: " nil nil
          (and (member cd-path '(nil ("./")))
               (null (getenv "CDPATH"))))))
  (cd dir)
  (...))

The `...' part makes use of the current value of
`minibuffer-completion-predicate'. It expects the value that that variable had
before this command was entered.

It turns out that I now need to bind `minibuffer-completion-predicate' in the
interactive spec. Otherwise, it has the value that is used for
`read-directory-name', which is `file-directory-p'.

(defun foo (dir)
  (interactive
   (let ((minibuffer-completion-predicate ; PROTECT IT
          minibuffer-completion-predicate))
     (list (read-directory-name
            "Dir: " default-directory default-directory
            (and (member cd-path '(nil ("./")))
                 (null (getenv "CDPATH")))))))
  (cd dir)
  (...))

It took me a while to discover this.

There was no change in the definition of `read-directory-name' between the two
Emacs builds mentioned. There was apparently a change in how the `interactive'
code is treated.

Previously, any recursive minibuffer use in the `interactive' spec was
apparently walled off from the body of the command, in the sense that
`minibuffer-completion-predicate' was not changed by that recursive minibuffer
read. That is no longer the case.

Is the new behavior intended?  Was it changed to fix some bug, as an enhancement
somehow, or by mistake?  Thx.