I think it's pretty widely recognized these days that type inference for local variables is a good idea. Most major languages that didn't previously have it have since added it.
Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.
TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.
How would dynamic typing have helped with this? Presumably all those different classes would still exist and create fragmentation and compatibility problems; they'd just surface at runtime instead of compile time.
The blog post is actually a bit imprecise; when it says "almost every Python program that touches cryptography goes through pyca/cryptography", that's only true if you don't count TLS. TLS in Python is usually done through the standard library's ssl module, which is mostly just a wrapper around OpenSSL. So that's basically an entirely separate workstream that doesn't really have anything to do with this post.
To be sure, evil websites will still be able to put misleading content around the element, and hope that the least savvy users will be fooled or will click the button out of confusion. But they can already do that with the existing JavaScript-triggered permission prompt.
Those were not "vision models" in the modern sense, but rather crude classifiers or OCR systems that were heavily dependent on human labor to handle many cases, because the vision models of the time sucked and were hardly capable of anything. The economic value of CAPTCHA-based data labeling went to zero when AlexNet (the first general-purpose vision model good enough for real-world use) was released in 2012; from then on, you could just have the machines do that work instead.
TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.
Both Carmack and Romero have praised Masters of Doom as a good picture of what things were like, which seems like a good sign since a lot of it is about a time when the two were at odds.
I think what the person you're replying to is trying to say is that the web-accessible error message (i.e., the one that JavaScript running in the sending page can read) is intentionally opaque and somewhat misleading, because a more helpful error message would leak information about the response that the sending origin isn't supposed to have. There's typically a more helpful error message in the dev tools (which JavaScript running in a page can't access), but you have to know where to find it.
A lot of people in this thread seem to be treating this situation as a referendum on the security of package repositories that allow anyone to create a package. Possibly because that's interesting to more people, since npm and PyPI are more widely used than Arch.
But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.
(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)
It seems obvious to me that they should get rid of this "orphaned" designation that allows anyone to grab a package and start pushing updates, because there's no circumstance under which that's a good idea.