WASM integration: I doubt an FFI style approach and wasm having to go through JS would be acceptable for every shared field access?

privacy is a source-language level concept, not a target language level concept. how JS structs are reflected in wasm is just an independent discussion IMO.

shared struct extend: the semantics of privates in JS is lexical. I think we may need a notion of protected here. Or at least a way to extract and represent the power to access private fields (which could be used to solve the wasm issue as well)

yes, the existing semantics of #-names binds us in a way. i don't have a good answer

the known options so far are:

1. no guardrails at all
2. volatile {} (people definitely hated unsafe)
3. private only

namely, the assertion from mark seems to have been "those getters are the intended public API provided by the author", while the contention is "from the consumer's point of view, unclear why public fields don't constitute the same intent"

is the main issue perhaps that there can't be private fields currently? so the conscientious shared struct author has no way to express the intent?

True, which is why I've held off on proposing it until there were more motivating use cases. I initially wrote up the proposal to address a concern around decorators surfaced by the Angular team:

class A { @dec(B) b; }
class B { @dec(A) a; }

This throws because B is not yet defined (even w/o TDZ it would have been undefined). You can address this with arrow functions, but its easy to accidentally pass an actual function and forget the arrow as you cannot readily distinguish between function types.

With references, this might be:

class A { @dec(&B) b; }
class B { @dec(&A) a; }

A second motivator is to support both conditional and unconditional output values w/o the overhead of destructuring:

Map.prototype.tryGet = function (key, &value) {
  // naive implementation
  if (this.has(key)) {
    value = this.get(key);
    return true;
  }
  return false;
}

let value;
if (map.tryGet(key, &value) && value > 0) { ... }

And refs could be used to pass a reference to a variable, field, or array element:

// private field and array element refs for atomics
Atomics.load(&this.#x);
Atomics.store(&ar[0], value);

// private field refs for friend classes
class Source {
  signal;
  #waiters;
  constructor() {
    this.signal = new Signal(&this.#waiters);
  }
}
class Signal {
  #waiters;
  constructor(&waiters) { // deref/bind 
    this.#waiters = &waiters; // ref, reified
  }
  subscribe(cb) {
    let &waiters = this.#waiters; // deref
    waiters ??= new Set(); // assigns to source.#waiters
    waiters.add(cb);
  }
}

A reified reference is roughly akin to a closure:

let a = 1;
let b = &a;
b.value; // 1
b.value++;
a; // 2

// rough desugaring
let a = 1;
let b = { get value() { return a; }, set value(v) { a = v; } };
b.value; // 1
b.value++;
a; // 2

Except that for fields its actually more like a Reference record in that it holds the object and property key, which is how something like Atomics could reach in and touch the actual field value. This is the only behavior that refs provide that isn't already possible in the language as a closure. My hope is, though, that engines could potentially optimize ref/deref pairs and avoid reification when it isn't necessary:

let a = 1;
let &b = &a; // ref/deref. 'b' and 'a' point to same binding

function &f(&x) { return &x; } // statically indicates ref return
let x = 1;
let &y = &f(&x); // ref/deref/ref/deref/ref/deref. 'y' and 'x' point to the same binding

For example:

const nameState = new Signal.State("Bob");
const helloComputed = new Signal.Computed(() => `Hello ${name}`);

let &name = &nameState.getMutableRef();
const &hello = &helloComputed.getImmutableRef();

name; // "Bob";
hello; // "Hello Bob";

name = "Alice";
hello; // "Hello Alice";

to make sure i understand, something like

shared struct S { publicField; } doesn't parse, but shared struct S { volatile publicField; } does