what i want for struct inheritance semantics:

• one shot initialization. even if we allow field initializers or user-programmable constructors, they get a fully initialized instance with all fields initialized to a sentinel (undefined, i guess)
• superclass's fields precede your own fields

That syntax sketch I wrote up a few months back has a lot of corner cases to handle future complexity, like:

• declaring whether a struct has a null prototype, or a "shared" prototype, or a TLS prototype.
• declaring whether a struct field is "non-shared" on a shared struct (i.e., a TLS-backed field).
• indicating whether a method is shared or non-shared, for a potential future that might somehow include shared functions.

I'd like to cut a lot of that for simplicity's sake. For example, every struct declaration has a non-shared prototype (a TLS prototype for shared structs). You can use extends null if you don't need the prototype, and we can just make that work as opposed to how class extends null doesn't work today.

Basically:

// non-shared struct
struct S1 {
  foo; // fixed-layout, non-shared field

  constructor() { } // realm-local constructor

  bar() { } // attached to realm-local prototype
  get baz() { } // attached to realm-local prototype
  set baz(value) { } // attached to realm-local prototype
}

// shared struct
shared struct S2 {
  foo; // fixed-layout, shared field

  constructor() { } // realm-local constructor

  bar() { } // attached to realm-local prototype
  get baz() { } // attached to realm-local prototype
  set baz(value) { } // attached to realm-local prototype
}

// null prototypes
struct S3 extends null {
  foo; // fixed-layout, non-shared field

  constructor() { } // realm-local constructor

  // cannot have methods/getters/setters
}

shared struct S4 extends null {
  foo; // fixed-layout, shared field

  constructor() { } // realm-local constructor

  // cannot have methods/getters/setters
}

// subclassing
struct S5 extends S1 {} // ok
struct S6 extends S2 {} // ok? S6 would be non-shared, even though S2 is declared as shared
shared struct S7 extends S1 {} // ok? S7 would be shared, even though S1 is declared as non-shared
shared struct S8 extends S2 {} // ok

The private names bit is tricky for shared structs, though, as you wouldn't be able to guarantee "hard privacy" if it were supported

Couldn't private declarations help?

Wiring up identical struct definitions between two workers would verify they have identical layouts.

I suspect if you had to explicitly register your structs, you could guarantee true privacy for private fields ;)