I actually did a === check for just that reason, since if you define _ = {}, then passing in a real object that is {} will also return true for _ == {}

Nope:

    js> a = {}
    [object Object]
    js> b = {}
    [object Object]
    js> a == b
    false

== only casts between certain primitive types, it doesn't do a deep comparison:

    js> x = null
    null
    js> y = undefined
    js> x == y
    true
    js> x === y
    false

Also undefined comparisons are still true with ===:

    js> var _
    js> _ === undefined
    true

But you're right, === should be the default choice, and only use == if you have a good reason.

It also conflicts with gettext libraries. The name '_' should be considered reserved for that purpose.

Not to be a jerk, but why? What if gettext isn't important to your current application? (I don't know a lot about gettext; I went and read the blurb.)

In pretty much any language which has a gettext implementation, "_" is the name used for the function/method/whatever which marks a string for translation. This is just as true in JavaScript (at least two JS gettext implementations that I know of use "_"). It's one of the few truly cross-language naming conventions I know of.

But libraries which expect to be able to use "_" for something other than gettext break this convention, and not only run the risk of screwing interoperability but also cause confusion for the (large number of) developers who are accustomed to "_" having a particular meaning.

True, but as long as _ is defined as a non-primitive type (namely an object or function) it can be used for both gettext (or underscore.js) and this currying function. All that's required for the currying is that comparison with anything other than itself is false.