Additionally, NaCl/libsodium is actually designed as a misuse-resistant API to perform real-world tasks, unlike GPG, where the API is "call this binary and use its crappy out-of-band signaling mechanism to figure out if anything went wrong".
This is what bugs me most about GnuPG - there's no real API, just an executable program with sometimes unreliable output. I mean, there is the GPGME library which wraps the executable calls in a C API (plus few other language bindings on the side), but it doesn't handle all the features the executable offers, often leaving you with a mix of GPGME API calls and "manual" calls to the gpg executable.
I'd welcome some full-fledged libgpg that would reliably implement gpg the executable's functionality, similar to e.g. libcurl vs. the curl executable.
Everyone would welcome it, but no-one's putting their money behind it. I suspect one of the real reasons that Signal uses a proprietary protocol (or rather, one of the real reasons that Signal was able to attract funding and improvements to GPG have not) is that having a locked-in userbase makes it easier to persuade VCs that there's a potential profit to be had. Whereas improving GPG would benefit everyone, but there's a tragedy of the commons around it.
I'm glad it's a good library. I was responding especially to "Make an arbitrary scheme on top of" whatever underpinnings one might choose, good or bad. That's not something we amateurs should ad lib where security matters.
We will undoubtedly have to integrate and access libraries like NaCl. But we should do so in keeping with best practices recommended by cryptographers (e.g. through NaCl's documentation), not by layering an arbitrary scheme on top.
