Just today, I finished writing my own low level go sqlite driver. I haven't published it yet. I really thought there was a need for it. I hate the database/sql integration that the other drivers have. Now I'll have to see if my driver has any need to exist.
This always seems to happen when I write something.
Your sqlite package totally fits my needs. My biggest problem is that I hate the database/sql layer. Connection pooling is completely unnecessary and surprising in a sqlite context. I honestly have no idea how anyone is using it with sqlite. The concept of a sqlite "connection" goes out the window. You can no longer use sqlite transactions in any normal way. You get locking issues if you don't force it into shared cache mode.
I've always wanted just a pure sqlite package with a one-to-one mapping of functions. Your driver is totally what I've always wanted to exist.
I've put up a preview version of my package if you wanted to look at it.
I ended up removing a ton of features, removing the database/sql driver, getting rid of all the "caching" of information that it does, removing callbacks (which I plan to re-add later), and renaming the methods to match sqlite function names.
It still has some niceties that I plan to keep, such as the Scan method to extract several columns with a single method call, and a RowData type to extract rows into a go map.
I found your project in Github and I'm going to suggest some things. There's a particularly nasty footgun that you might have by not having HAVE_USLEEP defined on UNIX. I'll open an issue.
Last I checked mattn's wrapper was for an older version and was missing some things, like registering an update hook (I could be wrong, been a while). I welcome a current, lower level wrapper. If you publish your code, I'd take a look.
And most people discount the learning experience. You don't really know how to do something until you've done it, with all its warts and edge cases and all.
This always seems to happen when I write something.