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.