Ich denke halt immer, wenn das Programmfundament nicht stimmt, macht es wenig Sinn neue Features draufzuprogrammieren. Oder anders: Wenn ich die 16-Bit-Engine rausschiebe, dann kann ich viele neue Features später nochmal programmieren, da nur 8-Bit-tauglich. Da wäre es dann doch mehr als logisch, das Fundament zuerst zu erneuern...
Das eine hat mit dem anderen nicht unbedingt viel zu tun. Das wird schon so getrennt sein, dass die Oberfläche nur wenig Berührungspunkte mit dem Unterbau hat, sprich, der ganze Kram "oben drüber" muss nicht neu gemacht werden wenn alles "unten drunter" auf GEGL (.. die Grafik-Library, die dann unter anderem auch 16-Bit Fähigkeit ermöglicht) umgestellt wird (was ja laufend immer in Arbeit ist, 2.6 macht meines Wissens teilweise schon Gebrauch davon).
Es ist aber auch niemanden gedient wenn es nach der Umstellung "knallt" und viele xcf-Dateien nicht mehr lesbar sind (unwahrscheinlich) bzw. andere Ergebnisse produzieren (schon wahrscheinlicher), weil es nun in der Berechnung der Ebenenmodi halt Differenzen gibt.
Keine Ahnung, ob jemand mal ernsthaft in Erwägung gezogen hat, auf ein neues Format (XCF2 oder so) zu wechseln, aber man müsste ja abwärtskompatibel bleiben und den alten Unterbau dann immer "in Petto" halten wenn der User eine alte XCF-Datei öffnet.. ich kann mir vorstellen, dass aber keiner diesen Aufwand betreiben will. Aber ich steck jetzt nicht so tief drin, andere lesen die gimp-devel-Mailinglisten, vielleicht wissen die mehr.
Wie schwer man sich mit manchen Sachen tut sieht man doch schon bei den
Ebenenmodi "Weiche Kanten" und "Überlagern".. beide sind seit Ewigkeiten schon identisch, was sie nicht sein dürften.... "Überlagern" verhält sich wie "weiche Kanten", was natürlich jetzt nachträglich ein Problem darstellt, da unzählige Dateien sich darauf verlassen dass sich "Überlagern" verhält wie es momentan ist.. eben falsch. Das gilt auch für die ganzen Skripte.
Siehe auch:
http://docs.gimp.org/2.6/de/gimp-concepts-layer-modes.html
Dort ganz unten.
Ich weiß nicht, wieviele Skripte ich schon gesehen habe, die "Überlagern" benutze.. "Weiche Kanten" wäre korrekter, dann hätte man eine Chance dass das Ergebnis auch nach der Umstellung auf 16 Bit (GEGL) auch noch eine Ähnlichkeit hat wie man es sich mal früher hingedreht hat.
Siehe auch:
https://bugzilla.gnome.org/show_bug.cgi?id=162395
..und den letzen Satz dort im besonderen... wie ich vermutet habe, das Problem der Umstellung ist doch ein größeres.