Surprising type check

try.lisp contains these two definitions:
(defun g (x) (print x) :foo)
(defun f (x) (values (g x)))

At the REPL do:
* (load (compile-file "try.lisp"))
* (f 3) => :FOO ; after printing 3
* (defun g (x) x) ; style-warning, but ok
* (f 3)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002D9E8F3}>:
  The value 3 is not of type (MEMBER :FOO).

Realizing that CLHS says that the compiler is permitted to assume all kinds of invariants about functions defined within the same file, this is probably permissible. However, unlike all the times when inferred types could theoretically be used to help optimize, but aren't, this example shows a use of a derived type that to me is unexpected and not terribly helpful.

In particular, if you define stub functions that ignore their args and return NIL, it is not going to work to load functions using the stubs, then redefine the stubs, then call them, unless the callers declare the stubs notinline.
After LOADing "try.fasl", G's type information becomes NIL, which is consistent with only functions in the same file getting this treatment. But I would consider this a bug in so much as the SBCL compiler doesn't usually wire in assumptions about functions unless the user has declared it. In fact I would consider it an accident that the check occurs at all, because if G were in tail position then it would not; but VALUES precludes a tail call.