Consider this bound set:

{ C<CAP1> <: t, C<CAP2> <: t, t <: C<? super Integer> }
(where CAP1 super Number and CAP2 super Integer)

18.4 says we should attempt to resolve t to 'lub(C<CAP1>, C<CAP2>)'.  Due to limitations of lub (see JDK-5052943), this is 'C<? extends Object>'.  But that type is not within the upper bound, C<? super Integer>, so resolution must fall back to generating a fresh variable.

A better solution would be to simply choose the upper bound -- it is, after all, known to be compatible with the lower bounds.

If lub were perfect, always providing an optimal answer, then this would be unnecessary.  But lub is not perfect, and probably never will be (not just because of practical constraints, but because, by design, the type system is not required to have perfect lubs).

Here's a test that should fail given the current 18.4 behavior:

public class LubVsUpper {

    interface C<T> {
        void take(C<T> arg);
    }

    static <T> C<T> pick(T one, T two, C<? super T> c) {
        return null;
    }

    static void testLowerBound(C<? super Number> superNumber, C<? super Integer> superInteger,
                                C<C<? super Integer>> cc) {
        pick(superNumber, superInteger, cc).take(cc);
        // C<CAP1> <: t, C<CAP2> <: t, t <: C<? super Integer>
    }
}

In practice, javac's implementation manages to come up with t=C<? super Integer>.  It's not clear what logic it's using to get there.