Static compiler chooses superinterface return type

I am using Vavr 0.10, which has the following type relationship:

Try<T> extends Value<T>

Value defines the method <U> Value<U> map(Function<? super T, ? extends U> mapper), which is narrowed in the interface definition for Try to return a Try<U>. When used in a functional pipeline, however, the STC infers Value<U> as the return type even when it knows that the previous value is a Try<T>, causing downstream type failures. Instead, it should infer that the return type is the more specific Try<U>.

I am inspecting this intermediate inference in Groovy-Eclipse, but the CLI errors I'm getting are exactly consistent with the erroneous inference. I will try to create a minimal replication after getting the ticket ID.

—
This feels like the same problem:

List<DeleteItemRequest> batch = createBatch() // from Amazon DynamoDB SDK 2
Map<String, List<DeleteItemRequest>> requestsByTable = 
  batch.stream().collect(toMap(DeleteItemRequest::tableName, List::of))

This results in the error

Groovy:Failed to find the expected method[tableName(java.lang.Object)] in the type[software.amazon.awssdk.services.dynamodb.model.DeleteItemRequest]

even though from the context it's clear that the type being submitted is DeleteItemRequest, and Groovy-Eclipse correctly identifies Stream<DeleteItemRequest>. Somehow the "inner generics context" of toMap isn't getting the information, which also accounts for the functional-pipeline glitch.