No subject

Object.prototype.setPrototype = function(proto) {
};

Of course that should be check for cycling chain, which can be
performance inefficient.

Another approach is "proxy" object between object and its
[[Prototype]]. For example:

Object.prototype.proxy = function(properties) {
    var nativeObject = properties.clone();
    nativeObject.__proto__ = this.__proto__;
    this.__proto__ = nativeObject;
	
    return nativeObject;
};

That will be solve cycling chain checking, and will allow programmers
for more intelligent extend of built-in objects. Of course that is
only example, but is in the nature of ES.

> Finally, mutating __proto__ on an existing object may break non-
> generic methods in the new prototype object, which cannot possibly
> work on the receiver (direct) object whose __proto__ is being set.
> This is simply bad practice, a form of intentional type confusion, in
> general.

If programmer know what he does with the power which you provide, he
never shadow/overwrite non-generic methods.

>> And I have a question. Why ES5 give control on values of internal
>> attributes? What will improve that? "Save" augmentation of built-in?
>
> (You probably mean "Safe" here.)

Yes, apologize for my English mistakes.

> All of these, but mostly to enable higher-integrity abstractions,
> including ones that mimic the built-in objects (including the DOM --
> more generally, all the notorious "host objects"; see also
> http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
> .
>
> We do not want the built-in objects to have all the power, including
> to make properties non-enumerable and non-configurable but writable
> (more on const below). The JS authors should have this power too, so
> the committee is not a bottleneck for innovation where such attribute
> control is necessary for integrity, emulation, or some other valid
> reason.

The most JS authors use these features for patch their design. And
interface which manipulate internal attributes looks like memory
inefficient. For each defined property I should create native object.
Instead of that they can think about more simple interface which
manipulate internal attributes. For example object initialiser can
improve that:

const DONT_DELETE = 0x4,
	  DONT_ENUM = 0x2,
	  READ_ONLY = 0x1;

var obj = {
	property  : value : DONT_DELETE | DONT_ENUM,
	property2 : value : READ_ONLY | DONT_DELETE
};


Best regards!