One strategy that's sort of similar to the "embrace" strategy described in the other answers is "acknowledge" -- not only do you explore the quirk, you explicitly acknowledge that it's a flaw or mistake in the language.
After all, languages are designed by humans, and humans are ultimately fallible creatures: I think it's ok to acknowledge in some cases that the language designers messed up, or were working under assumptions and constraints that are no longer relevant today. This lets you work in teaching moments about:
- The importance of planning and the realities of software maintenance/backwards compatibility
- The fact that everybody makes mistakes and its ok
- Demonstrate what balanced technical criticism looks like (as opposed to the annoying sort of "language fanboyism" some students seem to pick up)
You can then amp back up the enthusiasm after you've moved past the quirk and returned to the actual content to help emphasize what you ultimately think is important and worth focusing on.
To return back to your original question, I think whether or not you actually discuss quirks or brush over them depends on to what degree the quirks impact your students' ability to successfully write code.
For example, take the
a == b vs
a === b" rule is almost always what you want, so I would probably spend only a minute or so talking about the quirk (I'd probably spend most of that minute cracking jokes about JS, honestly), finish by mandating students must always use
a === b, then move on.
this keyword is scoped. This issue actually does come up fairly frequently in practice (especially once you start mixing together object-oriented and functional style code), so is something you probably do actually need to cover in some detail -- at the very least, you need to give students a good set of rules of thumb they can apply.
Another example might be
a == b vs
a.equals(b) in Java -- this distinction strikes at the core of several fundamental Java topics and so must probably be taught in detail at some point.
There are unfortunately some quirks that fall into a middle ground: not so easily brushed aside, but not really worth spending time explaining (for example, the broken interaction between Java arrays and generics). In those cases, it might be worth just engineering your homework assignments so students simply never run into those quirks, or just writing that portion of the assignment for them, with comments for the curious.