Jetzt wird mir langsam klar, wie du die Sache siehst.

Apache hat nur die Aufgabe, Requests zu interpretieren, und gemäss Datei-Typ entweder selbst zu handeln (bei statischen HTML-Seiten und Bild-Dateien) indem er sie unverändert zurückgibt oder sie aber einem CGI-Plugin übergibt, im vorliegenden Fall ein PHP-Interpreter. Je nachdem ob PHP als Shared Library oder als Fast CGI Prozess läuft wird eine Prozedur aufgerufen oder der Request wird via Sockets zum Prozess durchgeschleust.

Im Falle von statischen HTML Seiten liegt die ganze Funktionalität beim Apache. Ein 500er würde bedeuten, dass Apache selbst ein Problem (=Bug) hat, weil beim Ausgeben einer HTML-Datei kann wirklich nicht viel schief laufen. Aber es wird in dieser BB-Software wohl sehr wenige statische HTML-Seiten geben. Fast der gesamte statische Inhalt dürfte sich auf Bild-Dateien belaufen. Und damit ist die Geschichte mit Apache eigentlich schon beendet.

Der ganze Rest spielt sich da ab, was du als "Frontend" bezeichnest (heute wird nur noch mit JavaScript ergänztes HTML als Frontend bezeichnet; bei PHP ists halt ein bisschen komplizierter):

Was du als Frontender kannst ist zu beeinflussen was innerhalb deines Programmablaufes geschieht.
Genau das haben die, die die BB-Software geschrieben haben, gemacht. Und damit kommen wir zum PHP-Bereich (auf welche Art das Plugin läuft, weiss ich nicht, spielt auch keine Rolle).

Wichtig ist nur, dass wenn der URL-Pfad auf .php endet, der Request von PHP gehandelt wird. Das läuft so ab, dass der PHP-Interpreter die Datei nimmt und sie praktisch wie eine HTML-Seite behandelt, nur dass im HTML-Code Sequenzen eingemischt sind, die etwa so aussehen:

<?php

(PHP-Code der HTML erzeugt)

?>

In dieser Sequenz wird dynamischer HTML-Code erzeugt, der gemäss Parametern im Request erstellt wird.

In diesem Code können nun Fehlerbedingungen vorkommen, die unvorgesehen sind. Fehlerbedingungen, die aus Parametern herrühren werden behandelt, in dem eine Fehlerseite oder auch nur ein Fehlertext mit einer Fehlermeldung, die der Benutzer verstehen kann, erzeugt wird. Wenn aber im Code etwas passiert, was nicht vorgesehen war, wird PHP einen 500er an Apache zurückgeben, der dann so aussieht wie gezeigt, wenn nicht eine schöne Error-Page dafür gemacht wurde. Das hat nichts mit "Server" oder "Daemon" oder Apache oder weiss was zu tun.

Also: hätte jeder Request einen 500er erzeugt, wäre tatsächlich ein Fehler auf Apache-Ebene vorgelegen. War aber nicht der Fall. Nur wenige Seiten haben diesen Fehler erzeugt, daher ist es naheliegend, dass auf PHP-Ebene (="Frontend") etwas unvorgesehenes schief lief. Und in diesem Fall wird 500 und nur 500 und mit Absicht zurückgegeben, weil das der korrekte Code ist ("Server error"). Ein bessere Erklärung wäre: "Sorry, we fucked up, we have a bug."

Es steht dem Code übrigens auch frei, irgendwelche 400er-Codes zu erzeugen, oft werden 404er benutzt um billig anzuzeigen, dass etwas (z.B. ein Element in der Datenbank) nicht gefunden wurde. Oder ein 400er, um falsche Parameter in der URL zu beweinen. Und nein, auch ein 400er ist nicht "catch all".

Und ja: die gesamte HTML-Seite ist eine Einheit. Das einzige was gecacht werden kann, sind die Bilder, weil die nicht Bestandteil des HTML-Texts sind (es sei denn, das Bild wird In-Line codiert). Der ganze HTML-Text kann leider nicht gecacht werden, weil der dynamisch ist. So ist das nun mal.

Übrigens: In modernen Container-basierten Umgebungen läuft kaum ein Server noch im Daemon-Mode, weil das Logging und der Server-Prozess selbst auf diese Weise schwer handhabbar sind. Logging wird auf stdout und stderr gemacht, wo es abfang- und umleitbar ist.