assignment.type.incompatible when using <? extends E> where <E extends @Nullable T>

This is minimized from the real code (though that link doesn't include the nullness annotations, nor the additional type parameter that causes the problem).

$ cat Caller.java
import org.checkerframework.checker.nullness.qual.Nullable;

class Caller {
  <T, E extends @Nullable T> void foo(Multiset<? extends E> multiset) {
    Entry<? extends E> entry = multiset.someEntry();
  }
}

interface Multiset<E> {
  Entry<E> someEntry();
}

interface Entry<E> {}

$ checker/bin/javac -processor org.checkerframework.checker.nullness.NullnessChecker Caller.java
Caller.java:5: error: [assignment.type.incompatible] incompatible types in assignment.
    Entry<? extends E> entry = multiset.someEntry();
                                                 ^
  found   : @Initialized @NonNull Entry<?[ extends E[ extends T[ extends @Initialized @Nullable Object super @Initialized @Nullable Void] super @Initialized @NonNull Void] super @Initialized @NonNull Void]>
  required: @UnknownInitialization @Nullable Entry<?[ extends E[ extends T[ extends @Initialized @Nullable Object super @Initialized @Nullable Void] super @Initialized @NonNull Void] super @Initialized @NonNull Void]>
1 error

I believe this should be legal: The "found" and "required" are identical if you strip off the first two annotations, and for those annotations, the "found" looks to be a subtype of the "required."

Start by reproducing the failure with the provided Caller.java example and the NullnessChecker command. Compare it with the real usage in guava/src/com/google/common/collect/Maps.java around line 585. Done means the generic assignment is accepted without the assignment.type.incompatible error while preserving the nullness checks.