> some recommended interface of mature crypto libraries

Maybe for bubble code it'd be okay to just say "gimma a hash".

But most real code needs to interoperate with stuff. E.g. I need to send a SHA-256 from a JS client to a Python server. So there needs to be a consistent and portable "SHA-256" concept that everyone understands.

A cryptographic hash is not a complicated concept (even if developing one is).

I suppose you can think about whether you require collision resistance or merely second pre-image resistance, but the popular ones are all intended to be collision resistant anyway.

The interop situation with the CRC family of hash functions is terrible. Check this madness out:

https://bitbucket.org/martin_scharrer/crccheck/src/default/c...

Yeah all these discussions are rather aimed at people who implement cryptography or have to make a well-thought hash choice at some point.

As a developer you should use something like libsodium that has a default "hash" API. Underneath, the developers made the choice of choosing Blake2, but this is transparent to the user of the library.

If you do not have access to high level libraries like that, and don't want to loose time/dig too much into the topic, following standards (SHA-3) is easy.

Yes and no. After all, these are just modes using Keccak (think, say, AES-CBC, AES-GCM all use AES), so the choice depends more on the purpose than anything else. But indeed, the naming is confusing. Instead of SHA3-256, SHAKE256, KMAC256 and ParallelHash256, maybe they should have better named them SHA-3-hash256, SHA-3-xof256, SHA-3-mac256 and SHA-3-parallel256 (or so).