added a comment - - edited
I've investigated this a bit. This is a subtler issue than I originally thought. To summarize: we represent containers for static methods, fields, and classes as uninstantiated types (with typeArguments()==null). When a static method or field is looked up through a concrete (instantiated) class or interface, the compiler attempts to reinstantiate the field or method, including its type, which is a nested class, and thus has an uninstantiated container. However, type parameter substitution code still treats uninstantiated types as if they had explicit type parameters, and thus substitutes the actual type arguments. Later, inner class removal code pushes the type arguments forward unconditionally, because it assumes that container types would have been instantiated only in contexts where the type parameters would be accessible.
There are two possible ways of fixing this: (1) make sure that the types are always explicitly instantiated where necessary and fix the type parameter substitution code to only consider explicit type arguments, or (2) change the reinstantiation code to avoid doing type parameter substitution on containers of static members. (1) involves a lot of code changes that have to be done on a one-by-one basis, but (2) will result in more fragile code.