This is from "ilisp/comint-ipc.el":
;;;
(defun comint-prompt-status (old line &optional equal)
"Called by comint-process filter with OLD and LINE, return 'error if
LINE is an error, T if it is a prompt as determined by
`comint-prompt-regexp' or nil otherwise. Also set the status
appropriately by funcalling `comint-update-status'. If specified EQUAL
will be called with old and line and should return T if line is not an
error. OLD will be nil for the first prompt."
(if (string-match comint-prompt-regexp line)
(let ((error (or (if equal
(funcall equal old line)
(or (null old) (string-equal old line)))
'error)))
(funcall comint-update-status (if (eq error 'error) error 'ready))
error)
nil))
Notice that it binds a variable called `equal', which is the name of
a built-in function. `comint-ipc' uses both the value and function
cell of some symbols... It occurs to me that what can happen is that
if there is a function that relys on being able to store something in
the value cell of the symbol it sits in the function cell of, and
that symbol gets shadowed by being bound from a lambda list, like
`equal' is here, and then someplace down the call chain it gets
called on, it won't work right because of the shadowing.
I believe this is exactly the sort of thing that lexical scoping is
meant to prevent.
The other thing that occurs to me is that this must rarely happen in
practice. 100 monkeys clattering on 100 buttonboards might produce a
situation like this in 100 years? dunno... as always, YTMAWBK.