A [related topic was discussed here](https://sqlite.org/forum/forumpost/c01168e0fe?t=h), recently. It is not clear to me that having lots (or all) of the extensions (now published beside the SQLite source) embedded in the amalgamation is a good idea. There is a [separation-of-concerns argument](https://en.wikipedia.org/wiki/Separation_of_concerns) against doing so. I also like having a CLI shell with lots of extensions available without having to .load anything. (I have appreciated and used your collection of extensions.) But I do not find it annoying that the SQLite library itself is restricted to a narrower purpose than the ever-expanding shell seems to have. As suggested in that other thread, a good compromise would be for a gob_of_extensions.c to exist which would #include everything needed from [the extensions source subtree](https://www2.sqlite.org/cgi/src/dir?ci=tip&name=ext), with omissions controlled by #ifdef constructs. That might even become the shell's way of including extensions, which could alleviate your annoyance.