window.external is shaped the way the engine generates it

A deployed commercial agent lists the absence of this object among its own named failure messages, which means it treats window.external missing as a value worth recording rather than an error worth ignoring. That is a reasonable thing to watch: the object is a vestige, two search-provider methods surviving from a browser era that has ended, and exactly the sort of surface a build assembles carelessly or drops altogether.

But the assertion worth making is not that the object exists. It is where its methods live. On a real Blink build the object has no own properties whatsoever — the two methods sit on its prototype, because that is how the binding layer generates every interface it produces, without exception.

A replacement written to satisfy a presence test assigns them directly onto the object instead, since that is the obvious way to write one and since nothing in a presence test can tell the two apart. Measured on a current Chromium: zero own property names, both methods on the prototype, both stringifying in the engine's native form.

So the structural question separates a generated interface from a hand-made one at no extra cost to whoever is asking, which is what makes it worth asking. The row is gated on the MEASURED engine rather than on the user agent, because Gecko and WebKit either omit this object or shape it differently, and their doing so is a fact about those engines rather than a defect — so it declines there instead of inventing a cross-engine expectation.