I agree that there's definite problems with computed signals - it's possible that two setters feed into the same computed signal and could have been set in different contexts, plus the fact that they're computed lazily might point to the reader's context as the correct call-time context (i.e. coming from the other direction). So there's potentially three or more different options and not necessarily a good way to disambiguate all of them.

That said, if there's no way to access the context(s) that set the signal(s) that caused the recompute, then tracing in many UI frameworks is essentially sunk. In my experience, it's a very common pattern to have an event handler do nothing but update a signal. If the tracing framework initiates a trace in the event handler then the trace would simply die then and there, whereas we'd like to be able to link that trace to any downstream reactions/effects, all the way to the re-render.

More concretely, we have an internal framework that writes code (very roughly) like this:

class UpvoteButtonComponent {
  constructor(private readonly rpcService: RpcService, private readonly id: string) {}
  render(item: ItemDetail) {
    return <button on:click={this.onClick}>{item.getVotes()}</button>;
  }
  onClick() {
    this.rpcService.sendUpvote(new UpvoteRequest().setId(this.id));
  }
}
// in a totally different file:
RpcService.registerMiddleware(UpvoteResponse.typeId, ItemDetail.typeId,
    (response: UpvoteResponse) => response.getId(),
    (item: ItemDetail) => item.getId(),
    (response: UpvoteResponse, item: ItemDetail) => {
      item.setVotes(response.getNewVoteCount());
    });

In this example, there's a lot of loose coupling: the click handler just fires-and-forgets an RPC. The RPC service has some middleware registered that gets a response of a certain type and then indexes all the cached ItemDetail models by their ID, retrieves the matching detail, and updates its votes. The UI data binding then picks up this change and rerenders the component. What I need to be able to do is thread a trace through that sequence of loosely coupled triggers. The callbacks are all registered once, when the module is loaded, but they need to carry along the call-time context in order to preserve the trace.

How does this:

function f() {
  const scopeEnterable = new AsyncContext.Scope();
  scopeEnterable[Symbol.enter]();
  // do work
  // forget to exit scope
}

differ from this:

function f() {
  function* g() {
    using scope = new AsyncContext.Scope();
    // do work
    yield;
  }
  g().next();
}

Async functions would also result in a dangling scope

async function f(p) {
  using scope = new AsyncContext.Scope();
  // do work
  await p;
}

const { promise, resolve } = Promise.withResolves();
f(p);
// never call resolve()

Where I see a problem is

{
  using scope = new AsyncContext.Scope();
  // ...
  const innerScope =  new AsyncContext.Scope();
  innerScope[Symbol.enter]();
  // ...
}
// what happens to vars set on innerScope?
innerScope[Symbol.dispose]();
// what happens now?

One way I could envision this behavior would be something like this very naive implementation:

AsyncContext.run = function (ctx, cb) {
  using scope = new AsyncContext.Scope(ctx);
  return cb();
}
AsyncContext.Scope = class Scope {
  static #top;
  #prev;
  #ctx;
  constructor(ctx) {
    this.#ctx = ctx;
    this.#prev = Scope.#top;
    Scope.#top = this;
    // other scope setup work
  }
  [Symbol.dispose]() {
    if (this !== Scope.#top) throw new Error();
    Scope.#top = this.#prev;
    // other scope teardown work
  }
}

Each time you create a new Scope, you're pushing it into a stack. When you fail to pop a scope, you get an error.

// Doesn't keep 1 on the context stack
const createScope = ctx => new Scope(ctx, 1);
using x = createScope(ctx);
doStuff();

// Doesn't keep 1 on the context stack
const run = () => v.run(1, () => {})
run();
doStuff();

Where was doStuff before? If your original code was

v.run(1, () => {})
doStuff();

then it has the same behavior.

I'm talking about changing this

v.run(1, () => doStuff());

into this

const f = () => doStuff();
v.run(1, () => f());

or this

const f = () => 1;
v.run(f(), () => doStuff());

const createScope = ctx => new Scope(ctx, 1);
using _ = createScope(ctx);
ctx.get() === 1

Consider this:

const createScope = ctx => {
  new Scope(otherCtx);
  return new Scope(ctx);
}
using _ = createScope(ctx);

class Scope {
  // ...
  [Symbol.enter]() {
    if (!function.using) throw new Error();
    // Update Agent.[[AsyncContextMapping]]
  }
  [Symbol.dispose]() {
    // Restore Agent.[[AsyncContextMapping]] 
  }
}

using _ = (() => {
  runMyEntireProgramWithFunctionUsingEqualsTrue();
})();

using _ = {
  [Symbol.enter]() {
    runMyEntireProgramWithFunctionUsingEqualsTrue();
  }
};

Lets say you have an api like openFile(path) that you want to produce a resource. If you want enforcement, you want to write

function openFile(path) {
  const handle = new FileHandle(...);
  return { [Symbol.enter]() { return handle; } };
}

not

function openFile(path) {
  return { [Symbol.enter]() { return new FileHndle(path); } };
}

Otherwise people could just call [Symbol.enter]() repeatedly on the result of the same openFile call.

Otherwise people could just call [Symbol.enter]() repeatedly on the result of the same openFile call.

My hypothetical might be something like:

class NamedScope {
  name;
  #scope;
  constructor(ctx, name) {
    this.name = name;
    this.#scope = new AsyncContext.Scope(ctx);
  }
  [Symbol.dispose]() {
    using _ = this.#scope;
    this.#scope = undefined;
  }
}

using scope = new NamedScope(ctx, "foo");
...

with scope (ctx) {
}

or something. What you want to dispose is not a resource, and it doesn't fit within the semantics of using.

Like, if the definition of Scope was just

declare class Scope {
  constructor(ctx: AsyncContext);
}

That's essentially just {}, meaning everything is assignable to it.