Sadly, I've found yet another problem with section 5.2.4:

@Vetoed
class Pair<U, V> {
}

class SymmetricalPairProducer {
    @Produces
    public <T> Pair<T, T> produceSymmetricalPair(InjectionPoint ip) {
        return new Pair<T, T>();
    }
}

class Client {
    @Inject Pair<String, Integer> asymmetricalPair;
}

Even though the producer is only able to produce symmetrical pairs, CDI rules allow the symmetrical pair to be injected into the asymmetricalPair injection point:

• the required type is Pair<String, Integer>
• the bean type is Pair<T, T>
• both types are parameterized and have identical raw type and all parameters satisfy the rules:
  • the first required type parameter is an actual type (String), the first bean type parameter is a type variable (T) and the actual type is assignable to the upper bound of the type variable
  • the second required type parameter is also an actual type (Integer), the second bean type parameter is a type variable (T) and the actual type is assignable to the upper bound of the type variable.

It is clear that type parameters, when they contain type variables, should not be tested for assignability independently.