Beispiele für Probleme der identifizierten Problembereiche

Primäre Zielgruppe: Personen, die an Vorlagen arbeiten

Leerzeichen und Zeilenumbrüche im Vorlagen-Quelltext haben anders als in den meisten Programmiersprachen fast immer Auswirkung auf die Vorlageneinbindung, und können deshalb kaum zur Strukturierung des Vorlagen-Quelltexts genutzt werden. Ein Einrücken von Vorlagencode ist deshalb nicht (ohne Tricks) möglich und schon ein einzelner Zeilenumbruch kann oft zu unerwünschten Ergebnissen führen.
Code kann nur über HTML-Kommentare kommentiert werden.
Die Syntax verwendet zahlreiche geschweifte Klammern. Dadurch ist es schwer zu sehen, was zusammen gehört und ob etwas fehlt.
Da es keine Variablen oder Funktionen gibt, muss Vorlagencode oft dupliziert werden.
Weißräume werden bei benannten und unbenannten Parametern unterschiedlich behandelt.
Parameternamen können beliebige Zeichen enthalten. Dies kann bei unbenannten Parametern dazu führen, dass ein Teil des Wertes als Parametername identifiziert wird.

Das Bearbeiten von komplexen Vorlagen ist eine Form der Programmierung. Die meisten Werkzeuge, die man ansonsten üblicherweise bei der Programmierung zur Verfügung hat, fehlen hier jedoch.
Versionsvergleiche sind bei Vorlagen oft unbrauchbar.

Historisch gewachsene Namen von Vorlagen oder deren Parametern können praktisch nicht mehr geändert werden, da dadurch die Kompatibilität mit existierenden Vorlagen gebrochen werden würde. Uneinheitliche Namen sind somit kaum auflösbar.
Viele alte Templates müssen überarbeitet oder auf Lua migriert werden.

Es ist schwer Vorlagen zu verstehen, wenn sich ihre Funktionalität über viele Untervorlagen verteilt.
Es fehlen Tools, um zu analysieren, wie bestehende Vorlagen verwendet werden.
Weit verbreitete Vorlagen sind vor Bearbeitung geschützt, da fehlerhafte Änderungen fatal wären. Dies macht die Verbesserung dieser Vorlagen jedoch schwierig.
Es kann nicht ausreichend überprüft werden, welche Auswirkungen Änderungen an Vorlagen haben.

Primäre Zielgruppe: Nutzende von Vorlagen

Wie man die zur Vorlage passende Dokumentationsseite findet, ist für neue Mitarbeitende nicht klar.
Um die Dokumentation einer Vorlage zu sehen, muss man die Seite verlassen, die man gerade editiert.
Viele Vorlagen haben keine Dokumentation.

Man muss wissen, welche Parameter eine Vorlage hat, wie diese geschrieben sind und welches Eingabeformat sie erwarten.
Oft gibt es dabei Inkonsistenzen zwischen Vorlagen und zwischen Wikis

Den Inhalt von Vorlagen wie Infoboxen kann man nicht direkt bearbeiten, sondern nur in einem eigenen Fenster.
Wenn man oft dieselben Vorlagen nutzt, muss man ihren Namen immer wieder eintippen.
Man kann Parameter nicht formatieren, ohne Wikitext-Syntax zu verwenden.
Verschachtelte Vorlagen werden nicht unterstützt.
Es gibt keine Auswahllisten von erlaubten Werten (Enumeration).
Es gibt keine komfortable Oberfläche, um ein Datum auszuwählen (Datumsselektor).
Felder, die in der Regel das aktuelle Datum enthalten sollten, sind nicht damit vorausgefüllt.
Der Visual Editor kennt nur verpflichtende und optionale Parameter, oft gibt es aber Einschränkungen wie beispielsweise „einer der beiden Parameter X und Y muss verwendet werden“.
Der Visual Editor unterstützt keine Einbindung mit „subst“.

Der Visual Editor fügt leere Parameter hinzu, auch wenn dies gegen die Konvention verstößt.
Regeln zur Vereinheitlichung von Vorlagen finden keine Mehrheit.

Vorlagen machen den Quelltext unübersichtlicher.
Manche Vorlagen verlangsamen das Rendern von Seiten.
#ifexist und ähnliche führen dazu, dass Seiten in einigen Spezialseiten fälschlich als Links auftauchen.
Ruft man eine alte Version eines Artikels auf, so wird er nicht mit den damaligen Versionen der genutzten Vorlagen angezeigt, sondern mit den aktuellen. Dadurch ist es nicht möglich, sicher zu sein wie der Artikel damals aussah.
Für jedes Wiki müssen die „Standard“-Vorlagen entweder selbst neu geschrieben werden oder aus einem anderen Wiki importiert werden. Beides führt mit der Zeit zu Inkonsistenzen zwischen den verschiedenen Wikis.