A DESCRIPTION OF THE PROBLEM :
In JLS (I used v17 but you can refer to the latest one), Section 6.4, it says (emphasis mine):

    It is a compile-time error if the name of a local class or interface C is used to declare a new local class or interface within the scope of C, **unless the new local class or interface is declared within a class or interface declaration appearing within the scope of C**

Meanwhile in Section 8.1:

    It is a compile-time error if a class has the same simple name as any of its enclosing classes or interfaces.

While these two are not necessarily a contradiction (if we read "q unless p" predicate as "if not p, then q"), it is not clear as to what purpose this rule serves (or at least the part after "unless").

Take as an example:

class Test {
  public void foo() {
    class C {
      public void bar() {
        class SomeNested {
          public void xyz() {
            class C{} // Section 6.4 says nothing what happens in this case. Section 8.1 results in compilation error
          }
        }
      }
    }
  }
}

Now, after trying several compilers:
- Java HotSpot(TM) 64-Bit Server VM (build 20.0.2+9-78, mixed mode, sharing)
- OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing),
the result is the same:
$ javac Test.java
Test.java:7: error: class C is already defined in method foo()
            class C{} // Section 6.4 says nothing what happens in this case. Section 8.1 results in compilation error
            ^
1 error

The question raises as what is the purpose of the cited rule if the compilers apparently follows only 8.1?
- If that is the intended behavior, then the whole rule is redundant if not confusing since we can never reach that form of shadowing of local classes/interfaces
- Otherwise, there is a bug in the compiler. Perhaps it would be better if JLS clearly emphasized connection between these two rules or made it obvious that the cited rule in 6.4 takes precedence over the rule in 8.1.

Some context and discussion that led to this bug report: https://stackoverflow.com/questions/76938670/what-is-the-meaning-of-the-following-rule-in-jls-if-another-rule-makes-it-redund/76938961

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a Test.java file with the following content:
class Test {
  public void foo() {
    class C {
      public void bar() {
        class SomeNested {
          public void xyz() {
            class C{} // Section 6.4 says nothing what happens in this case. Section 8.1 results in compilation error
          }
        }
      }
    }
  }
}
2. In the terminal from the same folder where Test.java is located:
javac Test.java

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either it should have compiled due to the exceptional case in the cited rule from 6.4, or
the JLS should have not mentioned the cited rule from 6.4, or at least the part that follows "unless" connective, although that will make the rule describe just a specific case of the rule 8.1 (redundant).
ACTUAL -
The compiler fails despite the aforementioned "unless" clause from 6.4

---------- BEGIN SOURCE ----------
class Test {
  public void foo() {
    class C {
      public void bar() {
        class SomeNested {
          public void xyz() {
            class C{} // Section 6.4 says nothing what happens in this case. Section 8.1 results in compilation error
          }
        }
      }
    }
  }
}
---------- END SOURCE ----------

FREQUENCY : always