You make it once. It's maybe 10 lines of code, all inclusive and will not break other peoples code. If BRL change the code now, it will break more than 200 peoples code. You on the other hand could override the object iterator to return a link instead of a value without breaking any exsisting code, (including most of your own).
Oh, I'm not suggesting Mark change how EachIn itself behaves, that would, as you say, break everyone's code. It's much too late to correct that. However, it is not too late for Mark to implement a new command like Each, or EachInList that would allow us to iterate through lists properly.
A binary tree is always balanced when you create it. The problem you describe may arise only after millions of insert / remove operations, and only on specific data sets.
I'm not convinced... I looked at Mark's code, and considered what would happen if I inserted a mess of objects that were already sorted in order, and unless I was mistaken, what I found was that you'd get one at the top, then one to the left of that, then one to the left of that one, and one to the left of that one, and so on. If the list was using memory addresses for the compare, it seems likely that there too you would have a problem because now you'd mostly get numbers in increasing order.
One Eyed Jack:
I don't think thats true. Once you delete the child, both of their memory will be restored.
"Delete" the child? You can't "delete" anything in Max. You have pointers to stuff, and if you lose a pointer the object is freed, unless something else points to it. In this case, you lose the pointer to the child and the parent, but both the child and the parent have pointers that point at one another, and they are never freed as a result even though you yourself now have no idea where they are in memory and think they have been freed. The only way to solve that is to set the internal pointers for one or both to Null so they do not point back to one another. If you set the child's parent pointer to Null for example, the Parent will be freed because it has nothing pointing at it anymore. Then the Child will be freed, because the Parent was the only thing pointing at it.
But I bet it does involve creating your own type that extends the list type.
Isn't that the whole point of the object oriented paradigm?
No, the whole point of the OOP is not for everyone to have to correct flaws in a language so the creator doesn't have to fix them in a way which will then be standardized.