Tree/ListBase Component does not always select the correct XML object passed in via selectedItem

Steps to reproduce:

1. Create an XML data provider structure with two element nodes that are identical via XML.toString().
2. Assign the data provider as the data provider for a Flex 2/3 Framework tree component.
3. Assign the tree's selectedItem to the second "identical" node (in reading order).

Note that this is already done in the enclosed simplified test case. Using the test case, simply click on the second button, entitled "Select Second Grandchild", noting in the trace() console log that the tree did not select the correct node as specified by reference (via comparison of the two node's UIDUtil.getUID identifiers). The first button, which selects the first semi-identical node, works correctly.

Actual Results:

The wrong XML node is selected (the first node, in array order, matching the one passed in by "==" double-equality semantics).
See mx.controls.listClasses.ListBase, line 5765 for the comparison.

Expected Results:

The actual XML node passed in via selectedItem should be selected.

Workaround (if any):

If the two XML nodes are not identical via XML.toString(), they will no longer be identical via "==" double-equality semantics per the documentation. Thus, adding an additional unique attribute or child to each of the nodes will allow these formerly similar nodes to be correctly distinguished in ListBase and correctly specified via the selectedItem property. This can be done trivially by trying the assignment of a XML node to selectedItem first, then comparing the actual selectedItem to the one actually specified. If these do not match, the desired XML node can then be "decorated" with an unique attribute and set again as the Tree's selectedItem.

While this particular bug will probably be encountered rarely, an option to allow the use of "===" triple-equality semantics (which would compare the XML nodes by reference in this particular case) would be nice, as this would resolve the problem entirely while preserving the current behavior for all unaffected users. At present, I'm using the workaround above to resolve this issue, although this does somewhat "dirty" the XML structure with an unneeded attribute for each of the "overly similar" nodes.