The array-like values returned by querySelectorAll, getElementsByTagName / getElementsByClassName, element.children, select.options, etc. were plain objects with indexed properties and a length but no prototype. They therefore had no [Symbol.iterator], so `for...of`, array spread (`[...coll]`), and `forEach` all threw `TypeError: undefined is not a function` — the engine looked up the missing @@iterator and tried to call undefined. This silently aborted Bing's offline hydration: es-module-shims' `processImportMaps` does `for (const s of document.querySelectorAll(...))`, and the throw was swallowed inside a promise `.then` microtask whose chained promise had no rejection handler (no console output, no unhandledrejection). Fix: build one shared NodeList/HTMLCollection prototype at document attach that borrows Array.prototype's iteration helpers (@@iterator, forEach, entries, keys, values — including the JS-preamble forEach) and chains to Object.prototype, then point every collection returned by make_wrapper_array at it. The collections are now iterable and expose forEach, but — unlike a real array — do not gain mutators such as push/splice, matching browser NodeList semantics. The prototype is GC-rooted via the DOM bridge. Confirmed against the Bing scenario: the `processImportMaps` uncaught exception is gone and es-module-shims now advances to its next entry point (`importShim`), tracked as a follow-up defect in isu issue 377. The bing.com screenshot stays xfail under 280 because the snapshot/golden background images differ (isu issue 305) and the module feeds are uncached (isu issue 334) — neither is an engine bug. Tests: a we-js unit test (test_query_selector_all_is_iterable) and an e2e scenario (nodelist_iteration.we + page 58) assert for...of, spread, forEach, .children iteration, empty-collection iteration, and the absence of push. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>