getHiddenRecord feedback (from http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js )

gistfile1.js

  function getHiddenRecord(key) {
    if (key !== Object(key)) {
      throw new TypeError('Not an object: ' + key);
    }
    var hiddenRecord = key[HIDDEN_NAME];
    if (hiddenRecord && hop.call(key, HIDDEN_NAME)) { return hiddenRecord; }
    if (!originalProps.isExtensible(key)) {
      // Weak map must brute force, as explained in doc-comment above.
      return void 0; 
    }
    var gets = [];
    var vals = [];
    /* __DAVID_BRUANT__
    In case HIDDEN_NAME is compromised, this definition of hiddenRecord seems to
    provide a lot of authority since gets and vals are mutable and iterable ECMAScript arrays.
    It seems that only few opertions are used on these arrays (and thus needed)

    It intuit with no proof that reducing the authority provided by access to hiddenRecord
    make weakmap secure even if an attacker knows HIDDEN_NAME.

    It seems that the two above arrays and how they are used are a "naiveWeakMap"
    */
    hiddenRecord = {
      gets: gets, // get___ methods identifying weak maps
      vals: vals  // values associated with this key in each
                  // corresponding weak map.
    };
    defProp(key, HIDDEN_NAME, {
      value: hiddenRecord,
      writable: false,
      enumerable: false,
      configurable: false
    });
    return hiddenRecord;
  }

That works too. By why is it better? I haven't measured, by I expect it is typically slower due to the allocation and eventual collection of the fresh descriptor which is otherwise unused.

The other minor changes that came along was the removal of they "key" property in the hiddenRecord object. I would consider this to be an improvement.
Besides expressiveness, I can't say if it's better or not, especially not performance-wise.

If the deep reason of the hiddenRecord "key" property and the "hiddenRecord.key === key" test is the inheritance case, it may be as good to test "hop.call(key, HIDDEN_NAME);" (hop === Object.prototype.hasOwnProperty)
I don't know more about performance for this case, but the code would show more clearly the intent.

Changing the gist accordingly