While https://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html spells out a translation approach that "sorts state-related members – fields and constructors – into the value projection, and behavioral members – methods – into the reference projection", it is silent about nested types.

If an inline class V declares an inner/nested class, how do we want to translate it ? Likewise for a ref-default class declaring an inner/nested member type. Given
public inline class X {
    class Inner { }
    static X.Inner xi = new X().new Inner();
    X.ref.Inner xri = xi;
    public static void main(String [] args) {
        new X();
    }
}
Does the type X.ref.Inner make sense enough to be allowed to stand on its own feet ? Given enclosing instance has got to be non-null before an inner instance can be instantiated, are there interesting use cases of X.ref.Inner that warrant that type name distinct from X.Inner ?? Given X and X$ref are two distinct clases from the VM's pov, if class files were to encode both X$Inner and X$ref$Inner forms, how would type equivalence be established ??

My strawman answers: Inner/nested classes are translated wrt to the declaring class. i.e they are not sorted/migrated. If they happen to be declared in an inline class, they are translated as inner/nested classes of the inline class. If they happen to be declared in a ref-default class, they are translated as inner/nested classes of that class class. Class files encode only one type - anchored off of the declaration site. All alternate forms in source code are coalesced into the "normal form" in the class file. For example, both the fields xi and xri would carry the type X$Inner in the class file.

This is the behavior implemented by JDK-8244233

The present ticket is raised for any specification changes that are
called for when reviewed at a global level