dired with cons arg: behavior when Dired buffer named already exists

[Drew Adams]

(dired '("foo" "file1.c" "file2.c")) opens a Dired buffer named `foo' with only
files file1.c and file2.c.  This is a useful feature.  The doc says only that if
the arg is a cons then its first element is taken as the directory name and the
rest are the files to list.

But what should happen if "foo" is already the name of an existing Dired buffer?

What does happen is that the existing Dired buffer `foo' is simply displayed.
That is, the explicit file list is completely ignored.

Wouldn't it be better if buffer `foo' were updated to list only the included
files?  That would be more useful, and it is certainly easy to recuperate the
original Dired buffer if for some reason the buffer name was a mistake.

The code in question is `dired-internal-noselect'.  This comment gives the
behavior rationale for the case where the Dired buffer already exists:

;; If there is an existing dired buffer for DIRNAME, just leave
;; buffer as it is (don't even call dired-revert).
;; This saves time especially for deep trees or with ange-ftp.
;; The user can type `g' easily, and it is more consistent with find-file.
;; But if SWITCHES are given they are probably different from the
;; buffer's old value, so call dired-sort-other, which does
;; revert the buffer. A pity we can't possibly do "Directory has
;; changed - refresh? " like find-file does.

(DIRNAME is a typo here - the argument is actually called DIR-OR-LIST, and if it
is a cons then the name is just its car.)

Note the rationale: If SWITCHES are not given, that is, if there was no
expressed intention to change the content of the listing, then just reuse an
existing buffer.  But if such an intention was expressed, then respect it.

Following that rationale, the behavior for a cons arg should be to respect the
explicit file list passed, not to simply ignore it and reuse an existing buffer.

And since it would be problematic to test the file list for differences from the
existing listing (whether or not it came from a cons arg previously), we should
always just update the buffer to reflect the file-list that is passed.  IOW,
with an explicit file list, never reuse an existing Dired buffer of the same
name.

WDOT?

Note that use of a cons as arg is not the typical use, and this use case has
sometimes been forgotten/overlooked when coding, so that there have been several
(recently fixed) bugs because of oversights.  I mention this because I imagine
that is the case here: it is not that we intentionally reuse the existing buffer
and ignore the file list.  We do that probably only because the coder wasn't
thinking about the cons case.  (The DIRNAME typo supports this supposition.)