Developer is here. 
I don't speak German so I used Google Translate.

You've issues with displaying the landing page as I understand correctly, 

Please note that the landing page is displayed only for non-logged in users.

So if you log in the site, you'll be redirected to the Activity page or the main page, depending on whether you've the Activity plugin enabled.

Please clarify your question if I misunderstood you.

Feel free to ask questions using your native language directly on the plugin page.

Die Landing Page funktioniert wohl nicht (wenn nicht angemeldet), wenn Du Deine Elgg-Seite als Walled Garden-Seite betreibst, wodurch nur angemeldete Besucher auf die Seiten (und Inhalte) zugreifen können. Beispielweise könnte das Landing Page-Plugin die neuesten Mitglieder und Gruppen nicht darstellen, weil der Zugriff auf diese Infos den Mitgliedern vorbehalten ist, sofern nicht explizit im Code des Plugins abgefangen. Die Landing Page / Index-Seite im Walled Garden wird auch durch andere View-Files erzeugt, die das Landing Page-Plugin wohl auch nicht ersetzt. Daher siehst Du die unveränderte Startseite von Elgg (mit dem entsprechenden Default-Hintergrundbild).

Das Plugin geht wohl auch wirklich nicht mit dem Custom Index (aka Frontpage)-Plugin von Elgg. Eine mögliche Alternative wäre das Widget Manager-Plugin zu verwenden (https://elgg.org/plugins/384604) und am besten noch das dazugehörige Widget Pack-Plugin (https://elgg.org/plugins/3122035). Ich weiss leider nicht, diese beiden Plugins zusammen mit dem Landing Page-Plugin verwendet werden können. Mit dem Widget Manager Plugin, hast Du unter anderem auch die Möglichkeit, eine Indexseite (Homepage / Landing Page) direkt auf Deiner Seite im Browser einzurichten. Die Seite setzt sich dann aus Widgets zusammen. Du kannst auch unterschiedliche Indexseiten für angemeldete und nicht angemeldete User einrichten.

Die Funktionalität, die Du beschreibst, wird es schon erforderlich machen, speziell für die Seite ein Plugin (oder Plugins) zu erstellen. Es sind ja nicht nur einzelne von einander unabhängige Funktionen, die Du benötigst, sondern es bestehen ja Abhängigkeiten zueinander (zu einem Nutzer würden nicht nur die Daten bzgl. welche Kategorien er abdecken kann gespeichert usw. sondern dies müßte dann auch auf einer persönlichen Seite noch alles dargestellt werden können und dann wiederum auch die Einbeziehung von Google Maps, was ja auch in irgendeiner Weise auf der Seite integriert werden muss).

Mit ein "bißchen programmieren" wirst Du da zumindest in kurzer Zeit nicht weit kommen. Das ist nicht eine Frage, ob Elgg dafür geeignet ist oder nicht, da dieselbe Ausgangslage meiner Meinung nach mit anderen möglichen Systemen genau so bestehen wird. Elgg bietet eine sehr flexible Basis und ist ein Framework für eine "Social Network", d.h. der Umgang mit Nutzeraccounts ist eine Funktionalität, die schon vorhanden ist. Weiteregehende grundlegende Funktionen sind ebenfalls vorhanden und ebenso "typische" Dinge, die man in einem sozialen Netzwerk wohl erwarten (z.B, Fotos, Videos usw.) gehen ebenso (teils über Plugins). Deine Anforderungen sind allerdings doch sehr weitgehend und doch auch sehr spezifisch, d.h. die Funktionen sind nicht so implementiert. An dieser Stelle kann man sich die einfache Erweiterbarkeit von Elgg zu Nutze machen. Allerdings muss man dafür schon ein gutes Vorwissen über Elgg (und das Basis-Knowhow von PHP, HTML, Javascript) haben, damit es in absehbarer Zeit implementiert werden kann (es wird trotzdem Zeit brauchen).

Ich beschäftige much nur hobbymäßig mit Elgg. Ich denke, dass ich trotz einigem an Wissen über Elgg trotzdem nicht (oder zumindest nicht "einfach") alles hinbekommen würde, was Du so an Vorstellungen hast. Ich denke, da wäre die Beauftragung eines professionellen, hauptberuflichen Entwicklers (am besten mit gutem Vorwissen mit Elgg) sehr angebracht. Das würde Geld kosten. Aber ich sehr da keine andere Möglichkeit, wenn Du nicht selbst die Möglichkeit hast, dir so viel Zeit zu nehmen, um zu lernen und es selbst zu implementieren.

Wie die Zukunft von Elgg aussieht kann ich nicht vorhersehen. Ich verwende Elgg jetzt seit etwa 10 Jahren und es war eigentlich schon immer so, dass nur relativ wenige Programmieren an Elgg selbst gearbeitet haben. Es hat immer ein Kommen und Gehen gegeben. An Elgg 4 wird gearbeitet und das sollte dann schon noch für einige Zeit verwendet werden können. Bei den Plugin-Entwicklern gab es früher wohl schon ein paar mehr. Allerdings gab es auch da auch schon immer eine Fluktuaktion. Die meisten der Plugins, die ich betreue (weil ich sie auch selbst verwende) wurden ursprünglich von anderen erstellt, die sie dann aber nicht mehr weiterentwickelt haben. Da ich sie aber weiter verwenden wollte, hab ich dann halt mal angefangen, selbst Aktualisierungen zu erstellen. Man muss allerdings auch sagen, dass die Betreuung von exisitieren Plugins schon einfacher ist (selbst wenn sie umfangreich sind) als die komplette Neuentwicklung von Plugins (wie in Deinem Fall notwendig). Da Elgg und die Plugins alle Open Source sind, besteht ja zumindest die Möglichkeit, dass man die Entwicklung übernehmen kann (oder jemand anderes einspringt). Wenn Du ein Closed Source Framework verwendest, ist im (gar nicht so unwahrscheinlichen) Fall dass die Firma, die so ein System anbietet, den Support einstellt, definitiv Schluss.

Meist ist der Übergang von einer Hauptversion zur nächsten ein Punkt, an dem Entwickler anspringen, da dann am meisten Zeit notwendig ist, um die Plugins zu aktualisieren (bei kleineren neuen Version behält Elgg die Kompatibilität bei). Bei dem derzeitigen Elgg 3 hinken die Updates (auch meiner Plugins) doch etwas nach. Ich kann nur für mich sprechen, wenn ich sage, dass ich die Updates schon machen werden, wenn ich zeitlich dazu komme. Bei manch anderen Plugins, deren Entwicklung von jemand gesponsert wurde, liegt es wahrscheinlich am fehlenden Willen des ursprünglichen Sponsors (und niemand der dafür eingesprungen ist), dass bisher keine neuen Versionen für Elgg 3 vorhanden sind. Da gibt es einige hauptberufliche Entwickler, die zwar die Plugins nach Fertigstellung hier umsonst anbieten, aber für die Zeit, die sie daran arbeiten, trotzdem erstmal von jemandem bezahlt werden müssen.

Vielen Dank für dein ausführliches Statement.
Für mein Vorhaben ist elgg vermutlich nicht das richtige.
Ich schiele mal Richtung CMS. Eventuell Drupal.

Ein Theme(-Plugin) wird von Elgg nicht anders behandelt als ein "normales" Plugin. Registrieren mußt Du ein Plugin nicht.

Ich habe mich auf den Mechanismus der "Plugin-Hooks" bezogen, bei dem man eine Funktion für einen bestimmten Hook registriert und damit das Verhalten von Elgg (und/oder Plugins) anpassen kann. Vorschlag: schau Dir mal den Code meines Album Link-Plugins an (https://elgg.org/plugins/1156536). Da ist im Prinzip nichts anderes drin als eine Funktion, die für einen Plugin-Hook registriert wird. Und in diesem Plugin hab ich das "richtig" gemacht, wie es erst ab Elgg 3.3 (oder vielleicht schon 3.1) empfohlen wird. Leider kann man diese Methode noch nicht in allen Fällen verwenden, da in manchen Fällen aus Kompatibilitätsgründen noch die "alte" Methode verwendet werden muss (die auch noch in den Docs erklärt wird).

Bei Elgg 3.3 bräuchte man nicht mehr zwingend die start.php-Datei. Falls Du nur den Hook registrieren mußt, geht das wie im Beispiel des Album Link-Plugins über elgg-plugin.php. Die Funktion, die der Hook aufruft, ist in einer Klasse definiert. Du müßtest ausgehend vom bestehenden Code nur die Funktions-, Datei- und Verzeichnisnamen an deinen Fall anpassen und Elgg findet alles automatisch.

Der Plugin-Hook in deinem Fall wäre dann vars:compiler, css (statt register, menu:user_hover). In der Funktion selbst bekommst Du aller Wahrscheinlichkeit nach mit $hook->getValue() das Array, in dem die CSS-Variablen drin sind:

$css = $hook->getValue();

$css['anchor-color'] = '#0078ac';

return $css;

Dann kannst Du die Werte existierenden Elemente ändern oder auch neue hinzufügen.

Falls Du eine View (nicht nur CSS sondern alles was unterhalb des views-Verzeichnis liegt ) in deinem Plugin überschreiben willst, muss die Unterstruktur in deinem Plugin die Original-Unterstruktur des anderen Plugins (oder von Elgg-Core) wiederspiegeln, z.B.

mod/tidypics/views/default/photos/css.php

kannst Du überschreiben mit

mod/DEIN_PLUGIN/views/default/photos/css.php

Du mußt nur darauf achten, dass dein Plugin unterhalb des oder der Plugins in der Liste der aktivierten Plugins angeordnet ist:

Plugin A

Plugin B

Tidypics

DEIN_PLUGIN

Dann kann dein Plugin alle Views überschreiben, die von den darüber liegenden Plugin geliefert werden (und eventuell ihrerseits schon von einem anderen Plugin überschrieben werden). Daher sind Theme-Plugins in der Regel ganz unten in der Liste einsortiert.

Ich kann mich nur nochmals bedanken!

Vielleicht solltest Du demnächst die Doku schreiben, anhand Deines Beispiels konnte ich das sofort umsetzen.

Ich hab zwar noch nicht verstanden, weshalb die Inhalte unterhalb des Directories /classes durch elgg-plugin.php automatisch gefunden werden, welche Kombinationen von [siehe: vars:compiler, css (statt register, menu:user_hover)] Parametern möglich sind und warum das mit dem Doppelpunkt mal als erster und mal als zweiter Parameter steht, aber das kann ja noch werden. Die offizielle Doku macht mich jedenfalls wahnsinnig.

Auf jeden Fall hat es funkioniert!

Das mit den Doppelpunkten ist jetzt bei diesen beiden Plugin-Hooks eher Zufall. Es gibt auch Hooks ohne Doppelpunkt in den beiden Parametern (http://learn.elgg.org/en/stable/guides/hooks-list.html). Man muss sich da sicherlich auch nicht alle Hooks merken (richtig oft werden wahrscheinlich sowieso nur wenige verwendet).

Ich befürchte, wirlich alles läßt sich in der Doku schwerlich ausführlich abhandeln. Es ist zu einem gewissen Teil eher auch zum Nachschlagen geeignet. Zum Teil ist es wohl leider auch so, dass die Doku von einem professionellen Entwickler für andere professionelle Entwickler geschrieben wurde (was ich beispielsweise auch nicht bin!). Wenn man mit den Konzepten schon vertraut ist, versteht man es wahrscheinlich ohne lange Erklärungen. Wenn man die Grundlagen nicht kennt, kann man sich schon mal blöd vorkommen. Ich versuche da meistens, in anderen Plugins den Code direkt zu verstehen. Das ist ganz am Anfang zwar auch nicht einfach. Aber es macht dann irgendwann "Klick", wenn man die immergleichen Muster / Strukturen usw. wiedererkennt.

Basis-Aufbau eines Plugins: http://learn.elgg.org/en/stable/guides/plugins/plugin-skeleton.html. Da wird auch das automatische Laden der Klassen erwähnt (mit Link zu mehr Infos).

Es ist nicht einfach, auf diese Frage, was zu bedenken ist, eine Antwort zu geben. Es hängt schon mal davon ab, wie viel Erfahrung im Bereich der Administration von Servern, Webapplikationen und vielleicht auch zumindest grundlegende Programmierkenntnisse vorhanden sind.

Eine Frage, die man sich ziemlich zu Beginn stellen sollte: was genau will ich eigentlich von dieser Webseite (nicht gleich Elgg-Webseite)? Welche Features sind wichtig (müssen auf jeden Fall vorhanden sein oder sind nur nice-to-have)?

Wenn es dann um die Frage geht, ob mit Elgg alle Anforderungen erfüllt werden können (mit dem Elgg-Paket selbst oder mit zusätzlichen vorhandenen Plugins) ist es auch hilfreich, zum Testen eine Elgg-Installation aufzusetzen. Dafür ist nicht gleich ein Server notwendig. Es kann für einen ersten Einblick / Überblick völlig ausreichen, sich Elgg lokal auf dem eigenen Rechner zu installieren (z.B. wenn eine Linux-Installation sowieso vorhanden ist oder auch mit XAMPP). An dieser Stelle wären dann zumindest grundlegende Kenntnisse, wie man eine solche Installation vornimmt, norwendig / hilfreich.

Falls nicht alle Anforderungen zu 100% erfüllt sind, gibt es verschiedene Möglichkeiten: statt Elgg was anderes nehmen. Oder gibt es jemanden im Verein, der das was fehlt, selbst programmieren kann (möglicherweise gar nicht kompliziert, das hin zu bekommen). Oder gibt es eine Budget, mit dem ein Entwickler finanziert werden könnte, der vielleicht auch beim Aufsetzen der Seite an sich helfen kann und auch notwendige Features umsetzen müßte und vielleicht auch zu einem späteren Zeitpunkt mit Rat und Tat (wenn auch nicht unbedingt kostenlos) zur Verfügung stehen kann. Es muss keineswegs notwendig sein, einen Entwickler zu bezahlen, wenn eigene Kenntnisse (und Zeit) vorhanden sind. Aus eigener Erfahrung kann ich sagen, dass ich zwar viel Zeit reinstecken mußte, aber im Laufe der Zeit genügend Erfahrung sammeln konnte, um mir meistens selbst helfen zu können.

Wenn sicher ist, dass alle Anforderungen an das Projekt von Elgg erfüllt werden können, ist es spätestens Zeit, sich um einen Webhoster zu kümmern (sofern auf dem Server des Forums nicht noch genuh Kapazitäten frei sind). Längerfristig ist ein Shared Server nicht aussreichen. Ein VPS-Server müßte es schon sein, da Elgg doch mehr Resources als ein einfaches Forum schluckt (je nach gewünschten Features und vor allem in Abhängigkeit der zu erwartenden User, die gleichzeitig online sein werden). Je nach Erfahrung kann man da einen gemanagten Serverplan wählen, der zwar teurer ist aber der Hoster kümmert sich um die Serverkonfiguration oder ein günstigeres Angebot, bei dem jemand vorhanden sein sollte, der den Server selbst (und nicht nur das darauf installierte Elgg) betreuen kann.