You could try this.

In the main app, keep a note of the modal form's handle.  In some OnAppShow event post (not send) a message to the
modal form, like:

PostMessage(ModalFormHandle,WM_MYSHOW,0,0);

In the modal form handle the message like:

procedure WMMYSHOW(var Message: TMessage); message WM_MYSHOW;

procedure TModalForm.WMMYSHOW(var Message: TMessage);
begin
  Show;

  if(Owner is TApplication)then begin
    (Owner as TApplication).BringToFront;

  BringToFront;
end;

If in doubt add Application.ProcessMessages anywhere and everywhere!

You will need to tinker with the above as it only conveys the concept.  It is extracted from code I used in a similar situation to yours with medium success.

Good luck
Simon

In our current WinXP environment, I have noticed this as well.  We have a custom message dialog that occasionally would get stuck behind other windows, giving the impression that the program is frozen.  This dialog happens to have a timer on it to allow some messages to disappear without user intervention, so we dropped some code to bring the window to the front in there (not an especially elegant solution).  

I've also noticed that my GExperts (which I love) "Clean Directories" process sometimes leaves the finished message in the back.

Switching back and forth via the taskbar tends to bring the hidden window to the front as well, not that you should try to communicate that to a large user base as a solution.

Brian
"There are 2 kinds of people in the world, those that divide people into two groups and those that don't.  I belong to the second group." - tag line I stole