EVALUATION

The effect happens because the mixOnZOrderChanging() method is not aware of such uncommon usage of the setComponentZOrder() method. To fix this, we should check the value of the oldIndex argument before passing it to the getComponent() method. If the oldIndex is equal to -1, then this is an insertion, and there's no need to call mixOnZOrderChanging(). The mixOnShowing() will correctly be invoked on the addNotify() and/or setVisible(true) invokations.
                                     

SUGGESTED FIX

$ sccs diffs -C Container.java

------- Container.java -------
*** /tmp/sccs.OkhFmi    2007-08-08 11:53:20.000000000 +0400
--- Container.java      2007-08-07 17:43:01.000000000 +0400
***************
*** 713,719 ****
               
               addDelicately(comp, curParent, index);
  
!              if (!peerRecreated) {
                   comp.mixOnZOrderChanging(oldZindex, index);
               }
           }
--- 713,726 ----
               
               addDelicately(comp, curParent, index);
  
!              // If the oldZindex == -1, the component gets inserted, 
!              // rather than it changes its z-order.
!              if (!peerRecreated && oldZindex != -1) {
!                  // The new 'index' cannot be == -1.
!                  // It gets checked at the checkAdding() method.
!                  // Therefore both oldZIndex and index denote
!                  // some existing positions at this point and
!                  // this is actually a Z-order changing.
                   comp.mixOnZOrderChanging(oldZindex, index);
               }
           }