ListChangeEvent.Change is documented to:

" The Change may consist of one or more actual changes and must be iterated by next() method. Each change must be one of the following: [wasPremutated, wasAdded, wasRemoved, wasUpdated]"

ListView's (probably similar for the other controls with MultipleSelectionModel, suspect the origin being in MultipleSelectionModelBase, didn't dig, though) selectedIndices/selectedItems violate that condition by having a change where all types queries return false (see failing test below).

This might be introduced by the fix to RT-37360 (at least that's where I saw one of my tests failling, which expected a single removed in the list change)

    /**
     * ClearAndSelect fires invalid change event if selectedIndex is unchanged.
     */
    @Test
    public void testChangeEventSelectedIndicesOnClearAndSelect() {
        if (!multipleMode) return;
        // init with multiple selection
        int start = 3;
        int end = 5;
        getSelectionModel().selectRange(start, end);
        int selected = getSelectionModel().getSelectedIndex();
        ListChangeReport report = new ListChangeReport(getSelectionModel().getSelectedIndices());
        getSelectionModel().clearAndSelect(selected);
        assertEquals("sanity: selectedIndex unchanged", selected, getSelectionModel().getSelectedIndex());
        assertEquals("single event on clearAndSelect already selected", 1, report.getEventCount());
        Change c = report.getLastChange();
        while(c.next()) {
            boolean type = c.wasAdded() || c.wasRemoved() || c.wasPermutated() || c.wasUpdated();
            assertTrue("at least one of the change types must be true", type);
        }
    }