added a comment - - edited
+1 on all points. I'll begin work on an updated patch.
Yes, there is a deeper more interesting problem lurking here.
One question is what should result in reflection warnings and what in compile-time errors. (I think some types of reflection warnings should be promoted to errors.)
Here are some examples of current behavior with comments:
(fn  (Integer/valueOff :foo))
CompilerException java.lang.IllegalArgumentException: No matching method: valueOff, compiling:(NO_SOURCE_PATH:1:8)
^ Error because the compiler can statically see this is never going to work. Fine.
(fn  (Integer/valueOf :foo))
Reflection warning, NO_SOURCE_PATH:1:8 - call to valueOf can't be resolved.
^ This is never going to work either, but only gives a warning. A bit surprising; I'd prefer an error.
(fn [x] (.foo x))
Reflection warning, NO_SOURCE_PATH:1:9 - reference to field foo can't be resolved.
^ This could work. Fine.
(fn [^String x] (.foo x))
Reflection warning, NO_SOURCE_PATH:1:17 - reference to field foo can't be resolved.
^ This is never going to work if x is a String but x can be of any type at run-time. Personally, I think this should be an error...