let thing;
let raw = (v) => {
  thing = { v };
  return thing;
};
const result = callback(key, value, { raw });
if (thing && result === thing) {

so, ok, here is an alternate possible design which I don't hate:

add a new JSON.rawString which returns an opaque, frozen, null-prototype object with a new internal slot holding a string (which has been checked to be valid JSON - maybe even a valid JSON primitive?). this can be called by any code. if JSON.stringify encounters such an object, it serializes it to its internal slot

fwiw, in the R&T repository there has been a bunch of discussion about tagged strings (https://github.com/tc39/proposal-record-tuple/issues/258#issuecomment-947115796). This feels similar, since it's a string tagged with JSON.rawString.

(we are not looking to include tagged strings in the R&T proposal)

A naive replacer might do:

function serializer(value) {
  if (typeof value === "object") {
    if (Array.isArray) { ... }
    const result = {};
    for (const key in value) { ... } 
    return result; // uh oh, we've replaced the exotic object with an empty normal object.
  }
  ...
}

my point is that "void produces undefined which is a reified thing, not the absence of a thing" is true in a technical sense but it is also true in a technical sense that class {} is a base class but also extends Object.prototype, if you are being that kind of precise.

on the other hand, colloquially it is understood that class {} is a base class, and I argue that colloquially it would be easily understood that extends void means "does not extend anything"

The production
PropertyNameAndValueList : PropertyName : AssignmentExpression is evaluated as follows:
1. Create a new object as if by the expression new Object().
2. Evaluate PropertyName.
3. Evaluate AssignmentExpression.
4. Call GetValue(Result(3)).
5. Call the [[Put]] method of Result(1) with arguments Result(2) and Result(4).
6. Return Result(1).

~ ES3

Except that already has a well-defined behavior:

> class C { __proto__ = null; }
undefined
> var o = new C();
undefined
> o
C { ['__proto__']: null }

Just need decorators:

@extendsNull
class C {}

At one point I was thinking about this:

// not hoisted
// not reassignable
const function f() {} 

// ok
@dec
const function f() {}

// syntax error
@dec
function f() {}

i very much want

@bound
method () {}

to be a thing

One reason:

const getFoo = router.get('/foo')(() => {});
getFoo.name; // ""

// vs
const getFoo = @router.get('/foo') () => {}
getFoo.name; // "getFoo"

i just want @router.get('/foo') function getFoo() {}

oh god, this is the strongest argument against function decorators I've yet seen

Worst case, you can do:

const { getFoo, ... } = class {
  @router.get("/foo")
  static getFoo() {}
};

DI using parameter decorators is something like:

// service-c.js
class ServiceC {
  constructor(
    @inject("service-a") serviceA,
    @inject("service-b") serviceB
  ) { ... }
}

// main.js
import { ServiceA } from "./service-a.js";
import { ServiceB } from "./service-b.js";
import { ServiceC } from "./service-c.js";

const container = new ServiceContainer();
container.addClass("service-a", ServiceA);
container.addClass("service-b", ServiceB);
container.addClass("service-c", ServiceC);

const instance = container.getService("service-c"); // gets or creates a ServiceC from the container

And in test code, you can do:

import { ServiceC } from "./service-c.js";
it("test the service", () => {
  const mockServiceA = { ... };
  const mockServiceB = { ... };
  const serviceC = new ServiceC(mockServiceA, mockServiceB);
  // test serviceC using mock behavior from dependencies
});

The VS Code system has a decorator factory that is used to create the actual decorators used for injection, and names the decorators to coincide with the interface name of the expected input. As a result, your code looks something like (in TS):

// themeService.ts

// describe the service interface
export interface IThemeService {
  getColorTheme(): IColorTheme;
  readonly onDidColorThemeChange: Event<IColorTheme>;
  getFileIconTheme(): IFileIconTheme;
  readonly onDidFileIconThemeChange: Event<IFileIconTheme>;
}

// create a decorator for the service
export const IThemeService = createDecorator<IThemeService>();

// editor.ts
import { IThemeService } from "./themeService";

export class EditorService {
  themeService: IThemeService;

  constructor(
    @IThemeService themeService: IThemeService
  ) {
    this.themeService = themeService;
  }

  // code that uses themService
}

and someone in the meeting chat said:

[2:21 PM] Paul Leathers
Yes, VB arrays are the case I remember.

[2:23 PM] Paul Leathers
The call didn’t really return an lvalue. If the engine saw a(i) = x, it would perform a call to IDispatch::Invoke with the PROPERTY_PUT attribute set and the value to write as an extra argument.