> JavaScript has an entire class of bugs in the form of countless unexpected type coercions

Contra this tired sentiment, JS does not have "unexpected type coercions". If you're going to call what happens when, for example, adding an object and a boolean together "unexpected", the question becomes "What were you expecting when you wrote that code?" JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable, and (crucially) you are not _forced_ into writing any programs that use these dubious patterns. (Although, if you want to, that's your prerogative.)

There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken.

Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead.

> behaviours that simply don't exist in more compact statically typed languages

You're confusing matters. If you want static type checking when writing your program, then use a static type checker. Refusing static type checking and then complaining about it is more than a little bit silly.

> JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable

Well-defined maybe, but predictable? Not really. Intuitive? Absolutely not.

> There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken.

On the contrary, I don't believe that this is really the case. People can and often do run into these bugs in the wild because they take some input from either a user who does something unexpected, an API that returns something unexpected or a library that acts in an unexpected way and, rather than failing a logical assertion, the program continues with effectively junk data. Sanitising inputs can be surprisingly complicated too, especially when you don't know or understand the conditions you are supposed to guard against.

> Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead.

My point is not that the alternative is superior, for whatever definition of "superior" you are choosing, but instead that many statically typed languages will force you to think about that behaviour rather than proceed in ignorance.

> If you want static type checking when writing your program, then use a static type checker.

If you have to rely on what is effectively a linter to type-check for you to make sure your program won't do surprising things, that's not an incredibly positive indictment of dynamic languages as a whole.

> If you have to rely on what is effectively a linter to type-check for you to make sure your program won't do surprising things, that's not an incredibly positive indictment of dynamic languages as a whole.

Using TS or Flow definitely goes beyond what linters accomplish. That being said, your criteria for language quality sounds squarely-rooted in Static typing. Dynamic languages trade upfront taxonomic activity for rapid prototyping and then you come back post-prototype to analyze and ensure correctness. It's just a different approach. There are tradeoffs both ways.