I'm also still not to keen on using class name as a global registry key, its far too easy to have collisions (so many things would be called Node, for example). I'd prefer the keying mechanism be divorced from the name of the struct somehow. In earlier discussions I'd recommended using UUIDs and decorators, i.e.:

@RegisteredStruct("92057993-84c2-4015-9a4e-f1d3810db4a2") shared struct Foo { }

When evaluated, if the class name does not exist in the registry, insert a new entry whose key is the class name, and whose value is a description of the layout (i.e. order and names of instance fields, and whether the prototype is agent-local).
When evaluated, if the class name already exists in the registry, check if the layout exactly matches the current evaluation's layout. If not, throw.

1. that doesn't explain what happens if the name exists and the layout matches (I guess the default is do nothing, aka first one wins)
2. as I explained, any kind of simple agent wide registry keyed on string is a no go as it's effectively global mutable state that can be observed by the program (e.g. try to evaluate a shared struct definition with a new shape, see if it throws or not)

strawperson syntax:

// Special new declarative syntax
// Can't anything that actually evaluates, so no method decls, no static initializers, etc
layout SharedThingLayout {
  x; y;
  with nonshared prototype;
}

// Declaration that's actually evaluated and produces a constructor function
shared struct SharedThing layout SharedThingLayout {
  // allowed because SharedThingLayout has thread-local prototype, so there's a place to install m()
  m() { ... }
  // allowed because x exists in the layout
  x = 42;
  // disallowed because z doesn't exist in the layout
  z = "foo";
}

What happens if I do this:

shared struct SharedThing1 layout SharedThingLayout {...}
shared struct SharedThing2 layout SharedThingLayout {...}

but as you say, back to the layout idea. Would this be so bad, though:

shared struct S {
  with identity "46e6d6a9-7e62-46d9-9dfc-6288740eed8c"; // <- correlation at declaration level
  x;
  y;
}

anyway, i can live with something like:

• we have layouts, which are declarative and static, and are pretty restrictive. but they are deduplicated up front and the correlation thing "just works". bundlers will need to learn they can't be tree-shaken as normal
• shared struct declarations don't have to use a declared layout. if they don't, then they can have computed property names. you can have a correlation thing built in userland if you go that route

I'm talking about the idea I suggested in the meeting:

• no correlation api
• no struct reevaluation (always the same instance in a given thread)
• declarations correlated by either explicit token (i.e., with identity "foo"), or by source location

I don't think this works. that's back to the thing1/thing2 issue. If I can write:

layout L { ... }
shared struct S1 layout L { ... }
shared struct S2 layout L { ... }

then I have two or more potential prototypes to contend with in a given thread.

assuming L has a per-thread prototype declared, you have:

• S1 is its own constructor function
• S2 is its own constructor function
• instances of S1 are indistinguishable from instances of S2
• S1.prototype is the same slot as S2.prototype, so S1.prototype = foo is also reflected as S2.prototype === foo

Now I do this:

shared struct S1 layout L {
  foo() { print("foo"); }
}
shared struct S2 layout L {
  foo() { print("bar"); }
}
new S1().foo();

What should I expect?

shared struct {
  // the following 3 lines have static semantics
  with nonshared prototype;
  x;
  y;
  // this has evaluation semantics
  m() { }
}

?