So I've put together a reproducer according to your report and went into CDI spec to see if this is intended.

I think the current behaviour is correct because spec defines under which circumstances the assignability works, leaving an implication that situations not defined there aren't supposed to work.
And that's exactly the case here because (using types from my reproducer example) the required type is: MyInterface<T>
The bean type is: MyInterface<String>

So you actually have a required type parameter that is a type variable and bean type parameter that is an actual type - something spec doesn't describe.
The reason why this (IMO) cannot work is that if you then have an actual impl of MyClassWithInjectionPoint<T> (in my reproducer that is class MyClassWithIpConcreteType extends MyClassWithIP<String>), you inherit the IP but the only viable bean that can fit in here is really MyInterface<String>. Should the typesafe resolution allow more types, you might as well attempt to inject MyInterface<Long> here which will result in class cast exception.

As for how to make this work, I can see two options:

• Go for wildcard, that way you fall under second bullet point of spec rules and it will work.
• Mark MyClassWithInjectionPoint<T> as abstract which means Weld won't be forced to resolve an IP with type variable and will only resolve it for actual types defined in subclasses.

I was just mentioning it because for me it looked like a regression.

I would say that the fact it worked was a bug rather than anything else.