PATHNAME-SYMBOLOPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically, PATHNAME, TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING, REQUIRE are changed by this proposal to not allow symbols for their pathname argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE, DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or filename argument, and that DIRECTORY does not allow a symbol for its pathname argument. This is implied by the respective descriptions of those functions in CLtL, but not explicitly stated.
PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them there is probably a bug in the implementation.LOAD 'FOO) to mean (LOAD "FOO"). This is not explicitly allowed in CLtL, so such behavior has not been portable. However, such use is probably widespread among users of implementations that allow it (e.g., Common LISPCraft gives this form in an example.)FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table entry that was expected to exist and returned -false-. In systems that accept symbols as pathnames, this causes a reference to a file named "NIL" on some perhaps unexpected directory.
MERGE-PATHNAMES was in error because it accepted symbols.
We believe that this feature was accidentally introduced as a historical artifact and that it has limited utility. It is likely that the feature of accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied it from Maclisp. The reason Maclisp allowed a symbol here was that it did not have strings at all. While the feature was removed from Zetalisp before Common Lisp was defined due to the poor state of Zetalisp documentation at the time the change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a pathname, why can't a symbol be coerced into a pathname? An explicit decision was made early in the design of CL not to make all coercions transitive. For example, symbols coerce to strings (for string functions), and strings are sequences (and so can be mixed with other sequence types), but symbols are not sequences.
There is some sentiment for extending COERCE to allow explicit coersion of STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be disjoint.) While there is some sentiment for making this requirement in a separate cleanup issue, it would otherwise prevent both symbol->pathname and stream->pathname to have consistent meaning.