Carelessness versus craftsmanship in cryptography

Even if the XOR of the plaintexts doesn’t help an attacker, it still makes the encryption very brittle [...]

This paragraph is a little weird. Encryption at the point where a nonce has been reused isn't so much brittle as it is broken. You've got P1 XOR P2, neither of which are uniform random keystreams. It's highly structured. You don't need a P1 or P2 leak to begin attacking it.

I'm sure the libraries are quite bad, but I'd also say that there's nothing wrong with not supporting GCM or (heh) GCM-SIV. Very few libraries do provide a GCM-SIV. I don't love GCM, and CTR+HMAC is a perfectly cromulent composed AE system.

If AES just specified that you pick a random IV and prepend it to the cipher text, then users of crypto libraries wouldn't need to know what an IV is. Right?

Better JS option with randomized IV: https://github.com/Ekwani-Consulting/cryptou

From the post itself, I am not sure if the author had sent a patch or some sort of a pull-request to the affected entities. Namely pyaes and aes-js.

The response might've been different if the author had already given a patch, in somewhat backward-compatible way. This doesn't even have to be a functional patch, could be a simple `@warning: usage of default IV will cause insecure storage` similar annotations on the affected functions.

Another thing to remark (and which might've been off-putting for the authors of these libraries) that the author had used term mistakes in various places. Of course in an ideal world, ego should not or would not matter, but these libraries both seem to be quite stale and possibly the authors are having other $DAYJOB responsibilities. Making it difficult to fix things that they just receive complaints about. (I am also guessing these are quite many...)

Again in relation to the points above, it might've been better to say: Cryptography evolves over time, last years' best-practices get outdated, vulnerabilities being found, replaced with newer best-practices of this year. Same will happen next year too. It's not a deliberate mistake or any type of incompetency issue, this is a matter of ever-evolving field that we know and understand better...

While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...

You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is.