A lambda expression like the following is compatible with any target return type.

() -> { throw new RuntimeException(); }

The more-specific rules compare return types "for each return expression". If there are 0 return expressions, as in this case, the conditions are vacuously satisfied, leading to surprising results:

- One functional interface return type may be considered more specific than any other functional interface return type (regardless of, e.g., arity, void returns, nominal relationship, etc).

- A primitive return type may be considered more specific than any reference return type.

- A reference return type may be considered more specific than any primitive return type.

The effect as that, in any of these circumstances, an ambiguity error occurs.

Suggested text:
---
R1 and R2 are functional interface types, ***there is at least one result expression,*** and R1 is more specific than R2 for each result expression.

R1 is a primitive type, R2 is a reference type, ***there is at least one result expression,*** and each result expression is a standalone expression (15.2) of a primitive type.

R1 is a reference type, R2 is a primitive type, ***there is at least one result expression,*** and each result expression is either a standalone expression of a reference type or a poly expression.
---

The effect for primitive vs. reference return types is the same -- ambiguity -- but with a clearer explanation.

The effect for two functional interface return types is that the nominal relationship between the two matters, but any structural relationship is ignored. This allows for fewer ambiguities when one functional interface type is a subtype of another.

javac will need to be updated to match the different rules (it already fails to carefully match the quantifiers in the existing text, performing some tests at the top and some per-result-expression).