Unexpected @load binding triggers

steps to reproduce

run the attached example equal-list-load-binding.zul

and click the buttons:
1. remove an item
2. notify unrelated list

actual result

1. the first element from the ListModel is removed OK
2. the listbox reloads its model and reverts the model change (not expected)

expected result

1. the first element from the ListModel is removed
2. the listbox should not reload its model and remain unchanged

debug info

the second button calls notify change on the copiedList instance
still the @load binding referring to the original list reloads

root cause

Since Lists are considered equal if their contents are equal and in the same order I suspect the BindTracker identifies a wrong @load binding and reloads it.

originalList == copiedList => false (not the same instance)
originalList.equals(copiedList) => true (still equal)

I assume the Bind Tracking mechanism is keeping a lookup table (e.g. a HashMap based on equals) associating load bindings with both lists if they are equal, even if they are not the same. When notifying one of them the other one is loaded at the same time.