Review

Verified against Node source and the enabled parallel/test-process-prototype.js.

Correctness — all 6 test assertions covered

Test at parallel/test-process-prototype.js:1-16:

assert(process instanceof process.constructor);
assert(proto instanceof EventEmitter);
const desc = Object.getOwnPropertyDescriptor(proto, 'constructor');
assert.strictEqual(desc.value, process.constructor);
assert.strictEqual(desc.writable, true);
assert.strictEqual(desc.enumerable, false);
assert.strictEqual(desc.configurable, true);

PR effect:

So pre-PR fails on assertions 1, 5, and (depending on JS engine semantics) 4. PR fixes all.

Process.name = "process" rename

V8 surfaces #<Process> in error messages like Cannot delete property 'exitCode' of #<process> based on the constructor's .name. Pre-PR, the dummy function process() {} had .name === 'process', preserving the error format. Post-PR, the real Process constructor's name is overridden via Object.defineProperty(Process, "name", { value: "process", configurable: true }) — same result. ✅

The descriptor uses __proto__: null to avoid prototype-pollution influence on the descriptor object itself — clean defensive style consistent with elsewhere in the file.

The descriptor-only-with-value-and-configurable form means writable: false, enumerable: false are inherited from the existing .name descriptor (per Object.defineProperty "merge" semantics on existing properties). End state: {value: "process", writable: false, enumerable: false, configurable: true} — exactly Node's.

__proto__: null consistency

Both defineProperty calls use __proto__: null on the descriptor object. Defensive against Object.prototype.foo = ... polluting the descriptor's prototype chain. Good style.

Dummy _process removal

Confirmed via grep -n "_process\b" on the PR branch — only the path import ext:deno_node/_process/process.ts and _exiting from _process/exiting.ts remain (different concept entirely, the _process directory). The standalone _process = function process() {} is the only deletion.

Existing in-tree test compatibility

tests/unit_node/process_test.ts:1268-1274 tests process.constructor.call({}) doesn't throw (regression for issue 23863). Trace post-PR:

• process.constructor === Process
• Process.call({}) → this is {}, this instanceof Process is false → returns new Process()
• new Process() → this is fresh Process, EventEmitter.call(this) initializes it → returns the instance

No throw. ✅ Behavior change is "returns a new Process instance" vs. the pre-PR no-op return; the test only asserts no-throw, so it's covered.

Minor (non-blocking)

The PR description correctly mirrors Node's CreateProcessObject behavior — process originating from a FunctionTemplate named "process". Worth noting that the V8 binding also has process not exposed as a global constructor (you can't new process.constructor() outside Node's bootstrapping); Deno's process.constructor.call({}) test demonstrates this is observable. Pre-PR Deno mismatched in what process.constructor is; post-PR it's Process, callable.

Safety / performance

• Two Object.defineProperty calls at module load time. One-shot; no runtime overhead.
• No new allocations on the happy path.
• Object.defineProperty is from the global, but this is bootstrap code where primordials aren't yet a concern (it runs once at module init before user code).

LGTM.