Should I expand this to include other built-in libraries @Fil? Basically anything that I don’t think is really worth it to publish as a standalone library to npm? (We could always publish it to npm in the future if there’s demand to use a library outside of Framework, but most of these are pretty trivial…)

And should I add an “Observable imports” section to the Imports documentation that describes the observablehq: protocol?

Yes it would be good to clarify all of this. Doesn't seem blocking for this PR though.

I sketched out what it would look like to use e.g. observablehq:stdlib/sqlite instead of npm:@observablehq/sqlite, and it feels like the more we embrace observablehq:, the higher risk of confusion since we need to explain the protocol. Maybe we should stick with the original plan and try to publish these to npm and favor decoupling when possible. Though I think it seems reasonable for observablehq:stdlib to still be a built-in since it is tightly coupled with Framework (e.g. view depends on Generators.input). Hmm. 🤔

TODO Add documentation for observablehq: imports.