Whenever a full page is requested, a lot of things happen, that are easy to follow but hard to imagine. Let's imagine a call to the old-style module fsbetrieb which gives the detail page of a store, e.g. shows the wall as well as the pickup calendar and team overview.
The request we follow is /?page=fsbetrieb&id=4832

Web server request transformation

The "pretty" URL is decoded into /index.php?page=fsbetrieb&id=4832.

Front controller

The index.php front controller is called. It loads inc.php that includes:

config.inc.php for site configuration (credentials, URL, DB)
func.inc.php for global functions
Session.php for session handling via PHP Sessions / libFlourish Sessions
db.class.php for low level database class
Caching.php for URI-based caching (per-user and global for logged-out sessions)
Manual.class.php for mid/high level database access
lang/DE/de.php for global language strings
lib/view.inc.php as the "frontend component library"
lib/minify/JSMin.php to minify dynamic JS content

inc.php also

initializes $g_data with $_POST
initializes all globals that will hold content to be filled into the template ( $content_left, $js, $hidden and some more)
initializes $db with a new ManualDB instance
adds some global scripts/styles/hidden content

Module-specific controller

Back in index.php, the "old-style" controller (control/fsbetrieb.php in this case) is included (so executed at this point).

When looking at old-style modules, they normally consist of a big if/else-if block deciding between the different actions (like list, delete, new, update but maybe also more specific different functionalities). This is just plain procedural style, with just some bigger functions.

Most functions called are globals from func.inc.php or view.inc.php.

Module-specific controller: New-style application (e.g. page=basket)

When we look at the request handling of a new-style application, we find the statement loadApp('basket')instead of the controller itself. This includes the application itself (given as parameter to loadApp) as well as the core application. Stylesheet and javascript from the application is added to the output template. Control flow is handled over to the application by creating the controller ( BasketControl ) and calling the method defined by the GET parameter a (or index if none is given).

Afterwards, there is optionally another method called:

if(($sub = $app->getSubFunc()) !== false) // $app being the controller, e.g. $app = new BasketControl;
	{
		$app->$sub();
	}

Back to front controller

Afterwards, the menu is build and added to the output, flash messages (from Session of previous accesses) are added.

Finally, the page is rendered and stored in the cache if caching is enabled. In case it was a form submission (detected by $_POST['form_submit'] being set), a redirect to the same URL is done.