The ES5.1 spec for 220.127.116.11 has 'true' as the last argument to the Get/Put/Delete operations in its algorithm, i.e. throw a type error if the element attributes forbid a value change or deletion. test262 does not test for this and of the main browsers Chrome gets this wrong: it correctly blocks the forbidden updates, but silently ignores this instead of throwing an error, and hence also continues reversing instead of aborting.
From Paul Ruizendaal's email to the discuss thread.
Created attachment 53
Test cases that check true is passed to attributes if not throw a TypeError
Created attachment 64
Test cases that check true is passed to element attributes if not throw a TypeError
As noted in bug description, these 2 test cases fail on v8 debug and release version as it blocks the forbidden updates, but does not throw an error.
 The spec algorithm says that reversing progresses until it hits an error: it is not atomic, and an exception halfway through results in a half reversed array (cq. array-like object). Hence, just testing the elements beforehand for blocking attributes and throwing an early error is a no-go optimization.
The proposed tests use a 2 element array to reverse. Using a 4 element array and testing for "semi-reversedness" is a better test choice I think.
 Array.prototype.reverse also works on array-like objects. This is not verified.
 In real world implementations there is probably a "slow path" implementation that implements the spec algorithm literally and an optimized path for dense arrays. It might be useful to add a test with a dense 50 (or so) element array, just to test something that is likely on a fast path. The counter argument would be that test262 is about spec coverage, not code coverage.