So, I'm sympathetic, but also what @mqudsi said in the issue makes sense to me:

It's difficult to explain without delving into domain-specific information that would be out of place in the documentation what a PRF is and how it differs from a generic hash function, but that is the primary difference and where its strength and resilience comes from.

I'm not sure how I want to proceed here.

For me the issue came up when someone asked me how he can get access to the HashMap's hashing function, because he wanted to use it for password hashing, as it is apparently "cryptographically secure". That's why I would definitely like to change the wording around this. I'm not sure what the perfect approach would be without either requiring too much knowledge about hashing or being too imprecise.

Perhaps just something along the lines of "is cryptographically secure (but should not be used hashing sensitive content)"?

"is cryptographically secure (but should not be used hashing sensitive content)"

But SipHash is not a cryptographic hash function (which most people think of when hearing "cryptographically secure hashing function", which is also the first hit on google when searching for that term). A cryptographic hash function by definition requires first and second preimage and collision resistance, which SipHash just doesn't qualify for.

Even the wikipedia page about SipHash states

SipHash is fundamentally different from cryptographic hash functions like SHA in that it is only suitable as a message authentication code: a keyed hash function like HMAC. That is, SHA is designed so that it is difficult for an attacker to find two messages X and Y such that SHA(X) = SHA(Y), even though anyone may compute SHA(X). SipHash instead guarantees that, having seen Xi and SipHash(Xi, k), an attacker who does not know the key k cannot find (any information about) k or SipHash(Y, k) for any message Y ∉ {Xi} which they have not seen before.

Googles implementation of SipHash had a similar issue opened (google/highwayhash#28) which was resolved by completely rewriting parts of the documentation (google/highwayhash#31 (comment)). They seem to have ended up with

SipHash is a fast but 'cryptographically strong' pseudo-random function by Aumasson and Bernstein [https://www.131002.net/siphash/siphash.pdf].
-- https://github.com/google/highwayhash#introduction

Should we use the same wording and include the cite to the security considerations in the SipHash paper maybe as footnote?

NB: Your suggestion of "is cryptographically secure (but should not be used hashing sensitive content)" could be used to describe MD5 :)

I updated the wording in the book. The submodule needs to be updated in the rust-lang/rust repository, but apart from that I didn't find any references of cryptographic with regards to hashing within the stdlib docs.