See 6559158. The compiler is doing the right thing according to JLS 3ed 15.12.2, but the spec could be improved.
Comments
EVALUATION
In the non-generic example, 'BB create()' is return-type-substitutable with 'AA create()', so 'BB create()' hides 'AA create()' in class BB. There is no ambiguity for 'create' in BB.
In the generic example, 'Y2<S> create()' is not return-type-substitutable with 'X2<S> create()' because Y2<... extends Y2> is not a subtype of X2<... extends X2>. No hiding occurs and Y2 has two member methods called 'create'. Both are applicable (by subtyping and by method invocation conversion), and we only choose a most specific method on the basis of formal parameter types. There are none, so there is ambiguity. Even binding an actual type argument (Y2) to S doesn't help in this example, since the most specific method algorithm still has no formal parameters to go on. It is not obvious why Eclipse thinks that 'Y2<Y2> create()' is more specific than 'X2<Y2> create()'.
In the general case where both create's have (equal numbers of) formal parameters which use formal type parameters: If inference has produced formal parameter types that don't give a most specific method, then one could imagine that the generic method whose formal type parameter bounds "best fit" the actual type parameters is the most specific method. But the complexity is so high that it's not worthwhile.