Thanks for the review, good catch! @sapphi-red

I've updated this to conditionally enable arbitrary named exports based on build.target:

• When the target supports arbitrary module namespace identifier names, the output is unchanged (export { _x as "foo-bar" }).
• When it doesn't, reserved-word class names (e.g. switch, default) are still emitted as named exports via the ES2015-safe export { _x as switch } form (valid since ES2015). Only class names with illegal identifier characters (e.g. foo-bar) fall back to default-export-only access, matching the previous behavior.

The support boundaries match esbuild's compat table for ArbitraryModuleNamespaceNames (Chrome/Edge 90, Firefox 87, Safari 14.1, iOS 14.5, Node 16, ES2022).

Added tests for both supported (es2022) and unsupported (es2021) targets, plus the version-boundary detection.

• reserved-word class names (e.g. switch, default) are still emitted as named exports via the ES2015-safe export { _x as switch } form (valid since ES2015).

Would you send this change to @rollup/pluginutils? I think it's better to live there instead of having it here directly. We can patch it until it's merged.

@sapphi-red
Moved the handling into @rollup/pluginutils as requested — rollup/plugins#2002.

dataToEsm now emits the ES2015-safe export { _x as switch } (unquoted) form for keys that are valid IdentifierNames (reserved words / globals like switch, await), while the quoted arbitrary-namespace form (export { _x as "foo-bar" }, ES2022+) stays gated behind includeArbitraryNames. So Vite no longer needs to assemble those exports by hand.

While there I also fixed a latent bug: a default key produced a duplicate default export (SyntaxError: Duplicate export of 'default'). Filed as rollup/plugins#2001 and resolved by the same PR.

As you suggested, I've patched @rollup/pluginutils locally until that's released and simplified css.ts to delegate to dataToEsm (the manual export assembly is gone). I'll drop the patch and bump the dependency once #2002 ships.