Может стоит тогда ссылки на LI и XMLHttpRequest засылать как аргументы. Тогда в this будет то, что и должно в них быть. Или наоборот: первый аргумент - ссылка на текущий экземпляр, this - ссылка на LI/XMLHttpRequest.
Или вообще изврат: this - ссылка на объект с двумя свойствами, одно из которых ссылка на текущий экземпляр, а другое LI/XMLHttpRequest.

Такое уже пробовал. В любом случае, спасибо.
 

Такое уже пробовал. В любом случае, спасибо.

а это не самый распространенный путь в memory leak'и?

node.on... = function() {
    ...node...
}

я так подозреваю, что не обязательно даже использовать node внутри функции

можно id элемента в качестве параметра передавать
p.s. не понял, почему не получилось

самый :)

Все получилось (у меня, по крайней мере), просто сейчас еще раз перечитал ТС и понял: нужно !вообще! без замыканий. Т. е. даже id элемента нельзя: вообще никаких аргументов.
Только event, который сам по себе крепится. У event-а есть target, который в обоих случаях будет тем же this (или undefined).
Значит, остается только прицепиться к this. Нужно просто то, что хочется засылать как аргументы прикреплять к будущему this как свойства.

Примерно так:

перед строкой
document.getElementById(id).getElementsByTagName(" li")[i].addEventListener("click", this.clickHandler, false);
добавить
document.getElementById(id).getElementsByTagName(" li")[i].currentTree = this;
и далее в Tree.prototype.clickHandler получить текущий экземпляр можно так: this.currentTree

точно в обоих?
а this не должен указывать на li/xmlhttprequest соответственно в этих 2х случаях?

Не проверял, но вряд ли там будет что-то полезное в данном случае.

Он как раз на них и указывает. Т. е. нет доступа к текущему экземпляру. Вот я и предлагаю дописать его к li/xmlhttprequest.

[readystatechange] ie: srcElement - null, ff: target - xmlhttprequest
кстати да, я сначала подумал, что ты предлагал для обоих случаев к li this добавлять :secret: