Working around language quirks I find javascript to be a very pretty and neat language, once you understand how everything fits into a larger structure, which takes a lot of time and experience to understand. For many who haven't seen this inner beauty (for example, many of my JS students), they notice all kinds of "language quirks", which you can find enumerated all over the internet:

""           ==   "0"           // false
0            ==   ""            // true
0            ==   "0"           // true
false        ==   "false"       // false
false        ==   "0"           // true
false        ==   undefined     // false
false        ==   null          // false
null         ==   undefined     // true
" \t\r\n"    ==   0             // true


Source

Every language has its quirks (although few are as famous as JS in that regard), so what are some ways you've found effective to get students to focus on larger concepts instead of getting hung up on language quirks?
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 thing in JavaScript. I would argue that sort of quirk is ultimately irrelevant in the grand scheme of things: the "always use 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.

In other cases, trying to paper over or ignore quirks would be irresponsible. One example of this might be JavaScript's Byzantium rules on how exactly the 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.