Well then fork it and make it use HMAC with SHA256/512... Additionally, "Do not use this module" is bad advice if it leads to someone making their own MAC implementation, because that's almost always a bad idea. HMAC-SHA1 still is good security for this purpose.
I bet that as soon as standards bodies (like NIST) actively encourage you to use better hash functions (which they will probably do soon) the developer of this module will decide on what is safe enough for this purpose.
You advise to "fork it", but immediately after that you add the notorious "do not write your own" meme. Can you see the inconsistency of the messages?
Part of security is being up-to-date in regards to things like hashes. If authors don't update their own libraries and you need to tweak them manually, how is it different from "writing your own"?
I agree I'm a bit inconsistent, but the library is well written, and exchanging the hashing function is a trivial task. That's not really quite "writing your own". I just mean to discourage people who aren't 100% sure they know what they're doing.
I strongly agree with Armin: HMAC-SHA1 (note, the combo, it's not just the latter) is still good security for most applications you'd consider this library for.
While overrideability is good, wouldn't it be better to also be 'secure by default'? I'd imagine that SHA-2 would be more sensible default for most users.
I bet that as soon as standards bodies (like NIST) actively encourage you to use better hash functions (which they will probably do soon) the developer of this module will decide on what is safe enough for this purpose.