widen-unbox-widen vs JEP 455

[Stephan Herrmann]

I just learned that reference widening followed by unboxing (followed by 
primitive widening) is deemed a relevant conversion [1]. So I made sure that ecj 
can handle this in various situation, only to find out that this will make ecj 
produce code that is behaviorally different from what javac emits.

Here's my test code challenging this aspect of JEP 455:
//
<T extends Short> void typeVariableSingle(T single) {
     int i1 = single;
     System.out.print(i1);
     if (single instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (single) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
<T extends Short> void typeVariableList(List<T> list) {
     int i1 = list.get(0);
     System.out.print(i1);
     if (list.get(0) instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (list.get(0)) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
void wildcard(List<? extends Short> list) {
     int i1 = list.get(0);
     System.out.print(i1);
     if (list.get(0) instanceof int i)
         System.out.print(i);
     else
         System.out.print('-');
     switch (list.get(0)) {
         case int i -> System.out.print(i);
         default -> System.out.print('-');
     }
     System.out.println();
}
void main() {
     Short s = 1;
     typeVariableSingle(s);
     typeVariableList(Collections.singletonList(s));
     wildcard(Collections.singletonList(s));
}
//

compiled with ecj this gives
111
111
111

compiled with javac the program prints
111
1-1
1-1

Is this a simple bug in javac, or is there more to it?
thanks
Stephan

[1] see answers to 
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-August/004204.html