Can someone explain, and/or justify this?

Question

     x=app.activeDocument.viewPreferences.horizontalMeasurementUnits
     Result: PICAS
// so far, so good.  Just to be sure...
     x.toString()
     Result: PICAS
// now
     x+x
     Result: 4108374726
// huh?
     x+x.toString()
    Result: 2054187363PICAS
// and finally
    "units are "+x
    Result: units are 2054187363
I suppose there's some explanation why the measurement units for picas is secretly associated
with the integer 2054187363 and why it's a good idea.

Answer 1

> it still doesn't make sense that "picas" and friends should have these
> I'm-also-a-number behaviors that do make sense for special characters
The I'm-also-a-number behavior does not actually make sense whatever the enum you consider, it's just the way those objects work.
Note, however, that Enumerator instances do not have the cast Number (the typeof operator does return 'object'). What has been done when introducing these objects in CS5 is:
1. Making myEnum.valueOf() return a Number.
2. Overriding == and === so that myEnum can match a Number in both equal and strict-equal comparisons.
The reason for this, IMHO, was to preserve compatibility with previous versions (CS4 and before) where Enumerations—the collection of enums—were just pointing out to numeric values, that is, Numbers.
Thus, a syntax like (myUnit===MeasurementUnits.INCHES), or (myUnit===2053729891), or even (MeasurementUnits.INCHES===2053729891), still works from CS4 to CS5 without breaking existing code.
Now, about the meaning of these numbers, we know they are nothing but unique identifiers. Technically—and this is an old tradition in Adobe architecture—such identifiers are all built based on 4-character sequences.
In the case of measurement units, identifiers are formed using the prefix 'z' and 3 relevant letters from the unit name, usually the leading letters, e.g. 'zinc' for inches, 'zpic' for picas, and so on.
Then, ASCII codes of these characters are taken to build a number:
INCHES => z i n c => 7A 69 6E 63 => 0x7A696E63 (=2053729891 in decimal)
PICAS => z p i c => 7A 70 69 63 => 0x7A706963 (=2054187363 in decimal)
etc.
And you will check that +MeasurementUnits.INCHES is 0x7A696E63.
Anyway, your comment #5 highlights something else, based on the code:
var x = MeasurementUnits.picas;
var y = 2054187363;
var z = "2054187363";
We have checked, indeed, that x===y is true (see reason 2 above).
But we also can check, as you mention, that x===z is true!!! Which is not CS4-backwards-compatible at all and sounds highly irrelevant since x.toString()==='PICAS'.
I suspect that this strange case is a side effect of how the === operator has been overloaded. In my opinion, the hidden function Enumerator['==='](arg) mutely coerces the argument into a Number whatever it actually is. So the string z is simply taken as +z and that's why x===z also returns true. What Adobe should have done instead is:
// JS pseudo code
Enumerator['==='] = function(arg){ return 'string'==typeof arg ? this.toString()==arg : this.valueOf()==+arg };
…and then x===z would have been false, and x==='PICAS' would have been true ;-)
@+
Marc