68kWhy call FlushEvents between InitFonts and InitWindows?

Is anyone aware of any Apple documentation that explains the reasoning behind the specific place that they suggested calling FlushEvents during application initialization?

The Road Map chapter of Inside Macintosh I suggested the Toolbox be initialized this way:

BEGIN    {main program}
{ Initialization }
InitGraf(@thePort);            {initialize QuickDraw}
InitFonts;                     {initialize Font Manager}
FlushEvents(everyEvent, 0);    {call OS Event Manager to discard any previous events}
InitWindows;                   {initialize Window Manager}
InitMenus;                     {initialize Menu Manager}
TEinit;                        {initialize TextEdit}
InitDialogs(NIL);              {initialize Dialog Manager}
InitCursor;                    {call QuickDraw to make cursor (pointer) an arrow}

This order is repeated in many third-party books and sample programs of the 80s and early 90s.

The order of some of these is critical. For example, Inside Macintosh I says:

The InitFonts procedure initializes the Font Manager; you should call it after initializing QuickDraw but before initializing the Window Manager. Click to expand...

I understand the purpose of calling FlushEvents. It clears the event queue to prevent "stray" events. For example, if the user inadvertently triple-clicked an application instead of double-clicking it, you don't want that third click to be interpreted by the new application, especially if the new application opens a window with an active control right where the application icon had been in the Finder.

What I don't understand is why Apple suggested calling FlushEvents between InitFonts and InitWindows. What's the significance or importance of that? Why not call FlushEvents after all the Init functions? If the purpose is to clear unintended user input that occurred before the app finished launching, it makes sense that FlushEvents should be called as late as possible in the application's initialization process, after all the managers have been initialized and after the application has loaded in its menubar and done its other initialization. In other places, like Inside Macintosh II, it just says FlushEvents should be called "at the beginning of your application" without mentioning sandwiching it between two seemingly arbitrary Init functions.

Inside Macintosh I even says:

Before using the Event Manager, you should initialize the Window Manager by calling its procedure InitWindows ; parts of the Event Manager rely on the Window Manager's data structures and will not work properly unless those structures have been properly initialized. Click to expand...

And yet their sample code shows calling FlushEvents--part of the Event Manager--before having initialized the Window Manager by calling InitWindows.

In the rebooted documentation series of the early 90s, in Inside Macintosh: Overview, in Listing 4-2, Apple has changed the order to one that makes more sense to me:

PROCEDURE DoInitManagers;
BEGIN
   MaxApplZone;                   {extend heap zone to limit}
   MoreMasters;                   {get 64 more master pointers}


   InitGraf(@thePort);            {initialize QuickDraw}
   InitFonts;                     {initialize Font Manager}
   InitWindows;                   {initialize Window Manager}
   InitMenus;                     {initialize Menu Manager}
   TEInit;                        {initialize TextEdit}
   InitDialogs(NIL);              {initialize Dialog Manager}


   FlushEvents(everyEvent, 0);    {clear event queue}
   InitCursor;                    {initialize cursor to arrow}
END;