I'm having trouble finding any succinct explanation of what the modernc.org packages are all about, but as far as I can tell it looks like they're using https://gitlab.com/cznic/ccgo to translate the source of sqlite to Go and then just committing it to the repo. I have several objections to this:

• I'd like to move away from versioning blobs, building things from source properly instead.
• Much more importantly, I do not trust that tool. This seems like it's introducing a ton of complexity, I seriously, seriously doubt that it has seen enough battle testing to be trustworthy, and I would not be comfortable entrusting my data to a version of sqlite that has been run through that.

I think putting up with cgo is a much better option.

cgo transpiles Go to C, to be able to compile everything with gcc.
modernc.org/sqlite is a transpilation of the C amalgamation of sqlite3 to Go, so the standard Go compiler can compile it.

I can't decide which is more complex, but you're right that modernc.org/sqlite is younger - though it passes the same tests as sqlite3 does...
Getting rid of cgo may earn a few complexity/risk points.

cgo transpiles Go to C, to be able to compile everything with gcc.

I think the compiler uses linker magic to coordinate the Go/C calls rather than transpiling Go to C. It compiles the C bits with gcc, the Go bits with the Go compiler, then the linker does its magic.

Someone reported on the mailing list that perkeep no longer builds with GOOS=openbsd and GOARCH=amd64. If @bradfitz has had good luck with this package that eases my initial concerns, but it sounds like this is breaking users; do we want to consider reverting this unless and until modernc.org/libc supports openbsd?