The bug description says: "Our results match WinIE in all respects but one. We allow child frame names to take precedence over built-in and custom properties of the window object. This is the Mozilla behavior and is required to make some sites work because they use frame names that collide with built-in properties in Mozilla but not IE - specifically "toobar". See Radar 3870317." In <http://trac.webkit.org/changeset/31346>, test results were changed so that it is no longer true, without correcting the comment. It is also not clear to me whether the change to change the behavior was even intentional, and whether we broke rdar://3870317 as a result.
Also of relevance, the equivalent test for HTMLDocument (named the same but s/window/document/) doesn't have that comment but _does_ have the described behavior, as IE does. Right now I'm speccing what IE does throughout, so if the Window test's comment is accurate (and the test is not) then it would be good to know so I can change it.
My guess is this was an oversight and not an intentional change, and that I just didn't read the comment at the top of the test before verifying that mozilla had the same behavior and calling it a day. In part, this is fallout from having two getOwnPropertySlot methods, one in JSDOMWindow and one in JSDOMWindowBase, that both implement part of the functionality. We should merge them and fix this.
The spec now requires the Mozilla behavior, except that Mozilla doesn't currently support named getters on Window for anything _but_ frames.
We'll also need to extend the test to check for more than just window.location. The original radar and it duplicates are mostly about window.toolbar (very old versions of WebKit did not have this property, so some Safari-specific code broke when it was added).
We still have this comment - https://searchfox.org/wubkat/rev/9d623aaa1673388226c70b4490e73348297c48c2/LayoutTests/fast/dom/Window/window-special-properties.html#12