• When A handshakes with M:
  • M is able to establish that a PointA should have a PointM prototype and it will apply to every PointA it receives, from anywhere, within the scope of M's Agent.
  • A is able to establish that a PointM should have a PointA prototype and it will apply to every PointM it receives, from anywhere, within the scope of A's Agent.
• When B handshakes with M:
  • M is able to establish that a PointB should have a PointM prototype and it will apply to every PointB it receives, from anywhere, within the scope of M's Agent.
  • B is able to establish that a PointM should have a PointB prototype and it will apply to every PointM it receives, from anywhere, within the scope of B's Agent.

As such:

• M will be able to find behavior for both rect1.topLeft and rect1.topRight, because the handshake between M-A and M-B established that.
• B will not be able to find a behavior for rect1.topLeft because registries RA and RB are independent.
• A will not be able to find a behavior for rect1.bottomRight because registries RA and RB are independent.

However, if you use the same registry RAB with A and B:

• B is able to establish that a PointA should have a PointB prototype because the registry correlates both PointA and PointB with PointM.
• A is able to establish that a PointB should have a PointA prototype because the registry correlates both PointA and PointB with PointM.

Right I think an agent based registry can only work if:

• the internal agent wide registry is an association from type to local behavior definition
• there is a unique connection registry between 2 agents, and preparing a connection registry mapping (as creator or as a worker setting up), associates a connection specific string to a locally defined type only
• you can only populate the agent wide registry through connection registries.

that means a worker A connected to a worker B through M but not sharing the same connection registry will not be able share behavior throughout. I'm still wondering about the special parent - child relationship these connection based registries seem to have, and how you can only have one connection registry between 2 agents or things fall apart. I can't explain why exactly right now, but this all feels awkward.

to answer my own syntax question earlier, this could work:

shared struct class S {
  static nonshared prototype;
}

You want a syntax that:

• allows you to opt in or out of sharing for struct (for non-shared structs)
• allows you to opt in or out of sharing for instance fields (for shared structs)
• allows you to opt in or out of sharing for prototype methods (for shared structs in a future where code sharing exists)
• allows you to opt in or out of fixed layout for the prototype (for shared and non-shared structs)
• allows you to opt in or out of sharing for the prototype (for shared structs)
• maybe allows you to opt in or out of sharing for the constructor (for shared structs in a future where code sharing exists)
• maybe even allows you to opt in or out of sharing for static methods and static fields (for shared structs in a future where code sharing exists)

Does that cover everything?

that seems comprehensive

• for the MVP, i think "allows you to opt in or out of sharing for instance fields (for shared structs)" can be scrapped if we go with opting in or out of making prototype itself nonshared. if you need to express agent-localness manually, you can use a WeakMap
• i think "allows you to opt in or out of fixed layout for the prototype (for shared and non-shared structs)" shouldn't be a toggle but a choice we make. either we decide the fixed layout invariant extends transitively up the proto chain, or it's limited to instance layout only

So you either need to:

1. disallow privacy
2. disallow access to private names from one thread in another thread
3. weak privacy for shared structs
4. provide a friendship mechanism that you can somehow share in a trusted manner when handshaking with a child thread.

the private names thing can fall out of that, what i had in mind:

shared struct class S {
  #x;
  shared getX() { return this.#x; } // <- new exotic callable, can't close normal bindings, [[Realm]]-less, etc
}

So you do:

// structs.js
export shared struct S {
  shared #x; // weak shared private name
  
  nonshared getX() {
    return this.#x; // private name access is correlated for foreign struct types.
  }
}

// preload.js
import { S } from "./structs.js";
prepareWorker({ structs: { S } });

• Each agent maintains an independent registry of the shared struct types created within the agent.
• Each registry is linked bi-directionally to the agent that spawned the thread/agent.
• When spinning up a new Worker, you provide a set of shared struct types to correlate with the worker. In previous discussions these were exemplar structs, but we only really need the type identity of the shared struct type.
• When the worker starts up, it has a "preload" phase where it can handle its side of the handshake, and provide a set of shared struct types to correlate with the parent thread.
• During preload, the child thread cannot otherwise communicate with the parent thread via the worker/message port (any postMessage/onmessage ends up queued until the handshake has finished).
• In the agent registry, or in a global registry, you use this correlation information to establish how to treat any given shared struct in a foreign Agent.
• When you look up the prototype of a non-local shared struct, you interrogate the registry for an agent-local prototype to use based on this correlation information.
• By the time you can actually invoke [[GetPrototypeOf]], all information you would need to correlate and resolve the prototype of a given shared struct should be known to the system.

so here's my harebrained worse-is-better idea:

what if shared struct S { } declarations evaluated to something that has a special packageForClone(), which returns some object that can be reevaluated (like direct eval, but i guess safer?)

shared struct S {
  static nonshared prototype;

  // The static block gets packaged _as source text_.
  static {
    // Set up thread-local prototype
    this.prototype.method = function() { whatever; }
  }
}

let thing = S.packageForClone();
thing.evaluate(); // Get a constructor back that can create instances of the same layout. The VM knows it's correlated with `S`-instances. Re-evaluates the static block _from source text_ at the point of evaluation.

but i guess this doesn't work for your approach because you want to be able to

1. import { S } from some place
2. then correlate them

instead of

1. receive { S } via message from some coordination thread
2. set up S.prototype