Maurice 
sort(split(replace(concat(for l in thisSchKJ do
            let diff := number(l.Wochentag) - 1 - weekday(l.Kursjahrgang.'Beginn Vorkurs');
            for m in range(0, AnzWeek + 1) do
                    if l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m >= Kursjahrgang.'Beginn Vorkurs' and
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m <= l.Kursjahrgang.'Ende Vorkurs' then
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m
                    end
                end
        end), "  ","") , ","))
 

Maurice 
Das Problem liegt in dem Datentyp.
Du wandelst ein Datum mit concat in einen String um.
Das wandelst du dann mit Split wieder in ein Array um, welches jetzt aber ein Textarray ist und kein Datumsarray mehr.
Wenn du dann sort() anwendest, wird nach dem Typ Text und nicht nach dem Typ Datum sortiert und man bekommt ein falsches Ergebnis.
Die andere Schwierigkeit ist das verschachtelte Array als Ergebnis der ersten Schleife.

Deshalb ist die Funktion debugValueInfo() mit eine der wichtigsten Funktionen für das Debugging von Scripten.
Ein alter Grundsatz beim programmieren lautet:
Niemals Äpfel mit Birnen vergleichen. Sortenreines arbeiten ist oberstes Gebot.
 

let ArrDat := split(string(for l in thisSchKJ do
            let diff := number(l.Wochentag) - 1 - weekday(l.Kursjahrgang.'Beginn Vorkurs');
            for m in range(0, AnzWeek + 1) do
                    if l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m >= Kursjahrgang.'Beginn Vorkurs' and
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m <= l.Kursjahrgang.'Ende Vorkurs' then
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m
                    end
                end
        end), ",");
concat(sort(for n in ArrDat do
date(number(n))
end

Maurice 

debugValueInfo(for l in thisSchKJ do
            let diff := number(l.Wochentag) - 1 - weekday(l.Kursjahrgang.'Beginn Vorkurs');
            concat(for m in range(0, AnzWeek + 1) do
                    if l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m >= Kursjahrgang.'Beginn Vorkurs' and
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m <= l.Kursjahrgang.'Ende Vorkurs' then
                        l.Kursjahrgang.'Beginn Vorkurs' + diff + 7 * m
                    end
                end)

Mit dem Script erhält du ein verschachteltest Array. [[], []]
Darauf kann man kein sort() anwenden, da ea nicht alle Werte des Arrays sortiert, sondern jedes Array für sich.
Deshalb mache ich aus den vielen Array's erst einen kommaseparierten String, um daraus wieder nur ein Array statt vieler Arrays zu erstellen.
Dabei bleibt jedoch der ursprüngliche Datentyp auf der Strecke und eine Sortierung würde in diesem Zustand fehlerhaft sein. (Textsortierung - 11.09.2024 ist vor dem 12.06.2023)
Mit ein Hauptgrund, weshalb Anfragen kommen, warum meine mit format() definierten Werte falsch sortiert werden. (Auf den Datentyp achten!!! - format() ergibt immer Text)
Da jetzt ein Text-Array vorliegt, wird in einer Schleife der Text in eine Zahl umgewandelt und diese mit date() wieder in ein Datum.
Wenn ich jetzt sort() benutze, erhalte ich die korrekte aufsteigende Sortierung. (12.06.2023 liegt vor 11.09.2024)

Und nochmals der Hinweis wie wertvoll die Funktion debugValueInfo() bei der Entwicklung sein kann.
Auch eine eigen DebugPage ist bei Skripten die serverseitig ausgeführt werden sehr nützlich.
Dort helfen alert() und dialog() nicht, weil diese nicht angezeigt werden bei Ausführung des Script.
Hingegen hilft record(DebugPage,1).mehrzeiligesTextfeld1 := debugValueInfo(Variable, select, Schleife, etc)
Da kann man nachsehen, was im serverseitigen Script produziert wird.
So eine DebugPage habe ich in allen meinen Entwicklungsdatenbanken und bei Datenbanken, die ich untersuche. Oder ich nutze debug() und den Entwicklermodus im Browser.
 

Maurice Danke für die ausführliche Antwort.

Du schreibst:
Ist natürlich dann wichtig, wenn man auf mit format gesetzte Funktionsfelder zugreift und vermeintlich meint, das wären Datumtypen, die man dort abgreift.'

Genau DAS solltest du vermeiden.
Das Zugreifen auf Formelfelder zu weiteren Auswertungen ist ein NoGo.
FormelFelder sollten NIEMALS als  Datenfelder benutzt werden.
Zum Anzeigen von Informationen bei einem Dashboard ist es OK aber nicht um sie bei Auswertungen weiter zu benutzen.
Eine simple Berechnung in einem Formelfeld sum(select Tabelle.Ausgabe) mag in der Formularansicht keine große Performanceauswirkung haben. Wenn du aber eine Tabellenauswertung fährst, wo du Bezug auf das Formelfeld nimmst, wird bei jedem einzelnen Record der Tabelle die Formel neu berechnet. Wenn dann noch Schleifen dazu kommen, dann potenzieren sich die Berechnungen dermaßen, dass du möglicherweise Minutenlang den 'Kreisel des Todes' zu sehen bekommst.

Wenn du damit weiter arbeiten musst, dann nutze statt dem Formelfeld ein entsprechendes Datenfeld.
Das kann man auch über ÄnderungsTrigger der entsprechenden Bezugsfelder aktuell halten.
Ist zum Anfang etwas mehr Aufwand und manchmal etwas Tricky, zahlt sich aber bei der Performance erheblich aus.
Mit Anwachsen der Datenmenge kannst du dir durch Formelfelder, auf die Bezug genommen werden muss bei nachfolgenden Auswertungen, deine gesamte Performance versauen.
Da hilft dann auch kein Beschweren beim Support, dass die DB so elendig langsam ist.
Das hat in 95% der Anfragen einzig mit einem nicht gut durchdachten Datenbankdesign und fehlerhaften Scripting zu tun.