Given two functional interface types S and T, S may be more specific than T if i) S <: T, or ii) T </: S and the two types' function types are appropriately related.

The T </: S part of (ii) is necessary to prevent circularities in the relation -- if T <: S, it doesn't matter if T and S share similar (or, more likely, identical) function types, we're not going to let S be more specific than T. However, this restriction is narrower than might be intuitive: if T is *almost* a subtype, but not quite due to some subtle difference in, say, type arguments, users would prefer an error, rather than silently picking S.

15.12.2.5 is also narrower than the check used in type inference (18.5.4), because in that case it's necessary to predict whether T will have a chance of being a subtype of S before generating any bounds -- there's a point where the algorithm has to decide whether (i) or (ii) is the appropriate path.

15.12.2.5 is also narrower than javac in JDK 8.

Proposal: unify 15.12.2.5, 18.5.4, and javac by settling on a straightforward definition of "related functional interface type", and only allow (ii) when the two types are not related.