If you don't know what a front controller pattern is, start for example with these:

• Theory: https://en.wikipedia.org/wiki/Front_controller
• Example: http://symfony.com/doc/current/create_framework/front_controller.html

Front controller would introduce many benefits:

• Decreases code duplication
• Increases flexibility
• Increases security as the front controller can take care of tasks that a plugin developer may forget to implement individually to each individual plugin file
• Allows clean URLs (e.g. https://www.site.org/user/profile/123 instead of https://www.site.org/user/profile.php?id=123
• Allows centralized dependency management (e.g. autoload.php of Composer can be included in it)
• Attracts professional developers to Moodle

There is no reason why the new pattern couldn't work side by side with the old way. Web servers can be configured to check whether an URL points to an actual file. If this is the case, the file can be called directly. However, if no file is found, the request would be handled by the front controller.

An example:

• https://www.site.org/mod/quiz/view.php?id=123 points to an actual file in
  /var/www/moodle/mod/quiz/view.php so that file is served directly
• https://www.site.org/something/123 does not point to a file, so the front controller is used instead

The file used as a front controller is usually index.php located at the root directory of the project. Currently that file is used to serve Moodle's front page, so the only change to existing code at the very beginning would be to move that code somewhere else. (Maybe the front page could be the first page to be converted to be served through front controller?)

I won't yet go into details about the actual implementation, as the needed tasks and discussions should most likely belong to their own separate issues.