Since all three search boxes call the same open, they use the same hidden placement algorithm.  On Windows, the last position when closed is re-used for the next open for the duration of the IDLE session.  When IDLE is closed and reopened, the initial position is reset to a 'cascade' position.  What about Ubuntu?  Is it remembering across IDLE sessions? 

The 'difference' you noticed concerns 'is-a' relationships (via inheritance) versus 'has-a' relationships (via composition).  It is a perennial debate among some in the OOP community, with no resolution.  Python allows both.

IDLE uses both.  Different people? Same person, different times? Some perceived specific reason for each? I slightly prefer 'is-a' because it seems simpler, and inheritance does not bother me.  When we 'framify' the search widgets, I expect to use Frame subclasses.

Perhaps more important is grab-bag or kitchen-sink classes versus focused classes.  EditorWindow has a TopLevel, a Frame placed within the Toplevel, and, among other things, a Multicall-wrapped Text placed within the frame.  A method can be about any of them, and there are methods not about any of them, or about editing (open turtledemo).  There should be separate window, frame, and text classes with the methods appropriate to each.  I am sure that this would make the editor easier to learn, test and patch.

Modal or not is a separate debate.  Most recent opinions have been to make fewer things modal.  #24813 would make About IDLE non-modal. #24039 and #24760 include search dialogs.