Sequencing of "unsticking" stuck lambdas and method references is poorly defined. Sometimes one lambda's typing depends on information from another. Sometimes useful information will be provided by the method return's target type, and sometimes it's more useful to "unstick" during overload resolution.

Resolved (I think): a functional interface with descriptor parameter types depending on ivars that depend on the method's return type always go after overload resolution.
Resolved (I think): dependencies between stuck expressions are based on ivars in the descriptor parameter types and ivars in the descriptor return type; in the absence of a dependency (or to break a cycle), the leftmost one goes first
Not resolved: is there any use-site dependent behavior (that is, control flow based on what the bounds look like)? do we give up or skip a stuck lambda if an ivar has no bounds?