I added the following to the end of the Type.IntersectionClassType constructor, asserting that all elements of an intersection's "interfaces" actually are ClassTypes.

            for (Type x : interfaces_field) {
                if (!(x instanceof ClassType)) throw new AssertionError("bounds: " + bounds);
            }

(It might be useful to also try this with an assertion that the ClassType is, in fact, an interface, rather than a class or an intersection.)

4 tests fail:

tools/javac/generics/odersky/Test4.java
tools/javac/generics/typevars/6680106/T6680106.java
tools/javac/generics/typevars/6804733/T6804733.java
tools/javac/processing/6511613/clss41701.java

The last three are recovery situations -- a type variable declares a bad upper bound -- and perhaps the inconsistent use of "superinterfaces" is okay (although some unexpected errors might occur downstream; it may be better to replace the bad intersection elements with an error type).

The first is a case of inference creating an intersection of types without going through glb; here's the top of the stack trace:

java.lang.AssertionError: bounds: A,B,A,char[],java.lang.Object
	at com.sun.tools.javac.code.Type$IntersectionClassType.<init>(Type.java:1056)
	at com.sun.tools.javac.code.Types.makeCompoundType(Types.java:2267)
	at com.sun.tools.javac.code.Types.makeCompoundType(Types.java:2252)
	at com.sun.tools.javac.comp.Infer.instantiateAsUninferredVars(Infer.java:376)
	at com.sun.tools.javac.comp.Infer.access$700(Infer.java:64)
	at com.sun.tools.javac.comp.Infer$GraphSolver.solve(Infer.java:1652)
	at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2250)
	at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2242)
	at com.sun.tools.javac.comp.Infer$InferenceContext.solve(Infer.java:2257)
	at com.sun.tools.javac.comp.Infer.instantiateMethod(Infer.java:185)
	at com.sun.tools.javac.comp.Resolve.rawInstantiate(Resolve.java:563)

Since the distinction between the "superclass" and "superinterfaces" of an intersection type is important (for things like membership searches), it's simply wrong for inference to create malformed intersections like this and expect downstream javac behavior to be correct.