To me this looks like artifact of ECJ compiler:
given

class Fun {
  void fun(boolean b) {
    if (b) {
      System.out.println("then");
    } else {
      System.out.println("else");
    }

    while (b) { // line 9
      System.out.println("while");
    }
  }
}

ECJ 4.6.2 generates

    Code:
      stack=2, locals=2, args_size=2
         0: iload_1
         1: ifeq          15
         4: getstatic     #13                 // Field java/lang/System.out:Ljava/io/PrintStream;
         7: ldc           #19                 // String then
         9: invokevirtual #21                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        12: goto          34
        15: getstatic     #13                 // Field java/lang/System.out:Ljava/io/PrintStream;
        18: ldc           #27                 // String else
        20: invokevirtual #21                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        23: goto          34
        26: getstatic     #13                 // Field java/lang/System.out:Ljava/io/PrintStream;
        29: ldc           #29                 // String while
        31: invokevirtual #21                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        34: iload_1
        35: ifne          26
        38: return
      LineNumberTable:
        line 3: 0
        line 4: 4
        line 5: 12
        line 6: 15
        line 9: 23
        line 10: 26
        line 9: 34
        line 12: 38

where goto on a path from else branch is explicitly marked as belonging to a line of while statement. And so @marchof I'm wondering why you labeled this as "bug"?

@Godin I created this issue as a reminder to follow-up your observation without further investigation. My assumption was this is an issue on our side (like #321). So we can close this. Thanks for looking into it!

@marchof in fact I did this investigation prior to #503 (comment) , excuse me for a scarce comment. And my proposal in #504 (comment) was to preserve test of this interesting case maybe even with detailed explanation of why this happens at least to be able to refer to it in case of questions like "why such coverage is shown".

@marchof I'd like to reopen this as a request for enhancement:

As was said earlier - case is quite interesting and IMO deserves place in our validation tests.

Furthermore in a filter for finally, I've got second example when GOTO instruction should be ignored specifically for ECJ to avoid partial coverage. So maybe we can simply ignore all GOTO instructions, not counting corner cases of infinite loops while (true) ; and for (;;) ; ?

@Godin Interesting idea to remove all GOTOs. We can now easily add a filter for this and see what our regression tests say 😎

@marchof unfortunately I completely forgot that break and continue statements are compiled into GOTO 😞 , so that unlikely we'll be able to implement filter here. Most likely this also means that not safe to ignore GOTO in filter for finally. And anyway I wanna at least re-add case described here to validation tests.