Yes please. And to note, the name collisions are with the shell.c code, not the amalgamation. I still continue to wonder why extensions are being added to the "shell" diagnostic tool application rather than the sqlite3.c core amalgamation where they would be available not only to the diagnostic "shell" application but to everything that uses the sqlite3.c core (with appropriate enablements) including the diagnostic shell? There are only a very few that are only relevant to the shell application itself or that I haven't gotten around to extricating yet (completion, appendvfs, memtrace, sqlite3expert, dbdata). Every time an extension is added to the shell I have to remove it so that I can add it to the core where it belongs; or am I the only one that finds it annoying that functionality is available in the diagnostic shell (that are not shell commands) that are not available in the core? Note that having done this (added every extension plus several of my own, except the ones noted above, to the amalgamation) the size of sqlite3.c is (for me) now more than 10 MB however this does mean that *all* extensions and virtual tables are available everywhere that is built with the core (sqlite3.c amalgamation) including, for example, pysqlite2 and APSW, as well as to the shell. I haven't created the defines necessary to allow choice as to which ones are included though so by default most of them are.