I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for No

I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted). IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.