The Argon2 improvements are interesting and I'd love to hear about them.
Re: usability of other core primitives: I'll bite. Places where you don't get to solve a hard coordination problem to agree on a nonce matters. I know you document that you can't use a random nonce (and that's accurate), but I think that is an important safety regression.
> I know you document that you can't use a random nonce
Looking back at my manual, I understand it was easy to miss. But you can. You just have to use XChacha20, which gives you a 192-bit nonce, where the chance of collision even after 2βΆβ΄ messages is negligible. The high level constructions all use XChacha20, so random nonces are possible.
I really should re-arrange the order of presentation.
The slightly better usability mainly referred to the fact that functions that cannot fail return void. It's small, but the user is not left wondering whether the return value should be checked, or why the manual doesn't say anything about it. I tried to make the ordering of arguments consistent across the whole library. Easier interfaces have shorter names (no "easy" suffix).
Then there are opinions. Primitive functions are named after the primitive, because I don't believe in hiding those to the user. Fixed sizes are hard coded, because I don't expect them to change without changing the primitive itself. Constants like CRYPTO_ENCRYPTION_KEY_SIZE obscure the point somewhat.
Re: usability of other core primitives: I'll bite. Places where you don't get to solve a hard coordination problem to agree on a nonce matters. I know you document that you can't use a random nonce (and that's accurate), but I think that is an important safety regression.