LGTM. Verified against Node's lib/stream.js — Node's public API is Stream.destroy = destroyer (the implementation is named destroyer internally, but the export surface is destroy). So import { destroy } from 'node:stream' is the correct Node form, and destroyer was a Deno-specific divergence. Renaming the named export to destroy matches Node and keeps the existing Stream.destroy = destroyer assignment on line 126 consistent with the new export.

One observation inline: dropping the destroyer export name entirely is technically a breaking change for any Deno-specific code that imported destroyer from node:stream — though that name never existed in Node, so realistically very few users would have written that. Searched tests/, ext/ and found zero internal usages, so internally clean.

No CI signal yet (the PR is from an external contributor — only lint title and CLA have run; full CI needs a maintainer to authorize), but the change is so small that visual review covers it.

Renaming the named export to destroyer as destroy matches Node's lib/stream.js, which sets module.exports.destroy = internalDestroy.destroyer — same legacy-normalize helper that Stream.destroy is already wired to at line 126. CI green.

• nit: a one-line smoke test in tests/unit_node/stream_test.ts (import { destroy } from "node:stream"; assertEquals(typeof destroy, "function")) would lock the regression.

destroyer is loaded directly via core.loadExtScript in every polyfill that uses it (stream.ts:49, adapters.js:4, duplexify.js:21, compose.js:7), so renaming the node:stream export to destroy only affects userland — and matches Node's module.exports.destroy = internalDestroy.destroyer. CI is green.