Извини за грубость, погорячился.

<div id="elem">
 бла-бла-бла,<span>бла-бла,</span> бла-бла, Mr. Freeman.
</div>
<script>
el= document.getElementById("elem");
alert(el.childNodes)// список дочерних узлов
alert(el.childNodes[0])// первый в списке, ключ - число.
</script>

Опять же, сделай ключами цифры и перебирай...

Уже остыл )
childNodes - не хеш, это коллекция (NodeList), при чем read-only. В обычном же хэше все ключи должны быть уникальны, каждому ключу может соответствовать только один элемент, и ключи эти не должны меняться по мере добавления/удаления элементов в/из хэша. Если вы вставите дочерний элемент, то у всех последующих элементов индекс в этой коллекции поменяется (увеличится на единицу), в этом она повторяет свойства массива, хотя таковым тоже не является, поскольку содержит ко всему прочему еще и ссылки на элементы по name и id, которые далеко не всегда уникальны, и опять же, в эту коллекцию нельзя делать вставку/удаление.
Физически элементы связанны между собой через nextChild, previousSibling, что и является двунаправленным связанным списком с началом в firstChild и концом в lastChild. А коллекция childNodes обновляется движком по мере вставки/удаления элементов и служит только в качестве вспомогательного механизма для доступа к элементам, но ни в коем случае не для хранения этих элементов.

Кхм... Почитайте про коллекции на Википедии (ссылка туда). Коллекция - это просто условное название набора элементов, оно может быть представлено различными типами данных. В случае с childNodes она как раз таки представлена хешем.

Не факт. Есть различные способы разрешения коллизий в хеш-структурах, например, если для нескольких элементов ключи одинаковы, то ключ будет возвращать ссылку на связный список элементов с этими ключами("метод цепочек"). Но к JS это не относится.

К свойствам собственно хеша это не имеет никакого отношения. Если у массива это обусловлено способом хранения данных (они хранятся в памяти последовательно), то в случае с childNodes такие действия обусловлены логикой действия программы.

elem.parentNode.removeChild(elem)

nextChild и previousChild тоже не хранят элементы. Собственно, суть в том, что элемент - он просто есть. На него может быть сколько угодно ссылок - на элемент это не влияет (ну, почти). Если в C++, скажем, элементы добавляются в двусвязный список, а с удалением массива - исчезают, то здесь можно удалить хоть всех предков элемента - если на него будет ещё хоть одна ссылка, он будет жить. :D

Щито? Разрешение коллизий используется не для ключей, а для их хешей. Коллизии для ключей не рассматриваются в принципе. Считается, что все ключи уникальны, иначе непонятно, как различать элементы с одинаковыми ключами (Хотите хранить их все? Не вопрос — создавайте хеш-таблицу из список).
Никакие списки пользователю хеш-таблицы не возвращаются. Ему возвращается именно элемент, ассоциированный с нужным ключом.

Рассматриваются. В той же STL под C++ есть реализации ассоциативного массива, которые рассматривают добавление элементов с одинаковыми ключами - сохранение списка этих элементов.

Названия в студию.

multimap и multiset.

Вам w3 не авторитет?
И где здесь обращение к объекту childNodes? Вы обратились к объекту-хранителю связанного списка.
Ну во-первых, все эти механизмы не зависят от языка программирования.
Во-вторых в двусвязных списках ни где не используются массивы - только объекты и указатели, туда-сюда.
В-третьих, я разве писал, что nextChild и previousChild хранят элементы? Они хранят указатели на объекты элементов, как это и делается в любом двунаправленном списке. А коллекция childNodes является уже следствием этого списка, просто как дополнительный словарь-указатель (типа оглавления с закладками на уникальные name и id), и, подозреваю, что нигде во внутренних механизмах браузера не используется ни для рендеринга, ни для x-path обхода дерева. Поднимем исходники какого-нибудь браузера?

Почему не авторитет? childNodes - это коллекция, представленная хеш-таблицей. А не связным списком (аргументация: произвольное обращение невозможно в списке в силу его устройства. А childNodes прямой доступ - через индекс - предоставляет. Так что это более хеш, нежели список.) По этому пункту можно больше не спорить, имхо.

Это я так... Тут не буду спорить.

Это две разных структуры, которые нужны для разных целей. Я изначально спорил о том, что childNodes - это хеш-таблица. То, что перебор детей как двусвязного списка возможен - да, согласен. Сойдёмся на этом?

Ладно. Кстати, там не обязательно только хэш. Хэш там может быть для хранения значений по name и id, а для числовых индексов массив. Так было бы оптимальнее - чтоб не считать хэш-функции для числовых ключей. Все зависит от реализации.