I think npm itself actually always requires these fields, whether the package is published or not.

@ljharb npm requires them in the package's top-level package.json, but does not require them for package.json files that are in its subdirectories. The usage pattern that triggers this is the one documented here: https://nodejs.org/api/packages.html#type

This is useful in particular when a package transpiles TS into JS and provides both CJS and ESM endpoints: microsoft/TypeScript#18442 (comment).

I agree, but the package being published or not isn't the discriminator - it's required in any package, including a private:true one.

I'm not completely sure about "name", but "version" is certainly optional when a package.json includes "private": true. I use that often in e.g. documentation, when including such as npm workspaces in a monorepo.

Is there a plan to merge/close this PR?

I'm gonna close this in the interest of erroring on the side of being less confusing. While version is technically not required for private packages that aren't being installed into another directory, trying to explain that subtle distinction is more confusing that saying they're required.