Doppelpunkt in Aktion Tag-Feld importieren verändert Schreibweise Feldnamen

Eine ganz seltsame Beobachtung und ein Auffälligkeit, die sonst aber anscheinend keine Auswirkung hat:

Man erzeuge als Teil einer Aktionsgruppe: eine Aktion vom Typ "Tag-Feld importieren" für eine beliebige Quelle (z.B. %title%).

Formatstring: %album%: %title%
(bitte Schreibweise beachten)

Man speichere.
Anzeige in der Liste der Aktionen in dieser Aktionengruppe:

Tagfelder importieren "%title%: %album%: %title%

(das ist soweit ok)
Man bearbeite dieselbe Aktion erneut - und beim Öffnen des Bearbeiten-Dialogs die Anzeige:

Formatstring: %Album%: %Title%
Der erste Buchstabe des jeweiligen Feldnamens erscheint als Großbuchstabe.
Beim (ansonsten unveränderten) Speichern mit OK zeigt auch die Liste der Aktionen für diese Aktion:

Tagfelder importieren "%title%: %Album%: %Title%

Man kann die Änderung rückgängig machen und per Hand die ersten Buchstaben wieder auf Kleinschreibung setzen - dieser Zustand bleibt aber nur erhalten, wenn die Aktion nicht wieder bearbeitet wird.

Noch seltsamer:
Die Schreibweise wird nur beim Doppelpunkt als Trennzeichen verändert.
Wenn es anderen Text (zusätzlich) und/oder ein anderes Trennzeichen gibt (z.B. Bindestrich), bleibt die Schreibweise auch bei wiederholtem Bearbeiten wie eingegeben.

Bei einem kurzen Test mit Mp3tag v2.82 ist es mir nicht gelungen das beschriebene Verhalten nachzuvollziehen.
Vermutung: im Dialog "Tag-Felder importieren", Eingabefeld "Formatstring", in der Historien-Liste der Formatstrings liegen vielleicht "doppelte" Einträge vor, etwa so:
%Album%: %Title%
%album%: %title%
Wenn ja, dann einfach den unerwünschten Listeneintrag entfernen.

DD.20170609.1053.CEST

Noch mal zum Verdeutlichen: beim ersten Eingeben ist die Schreibweise mit Kleinbuchstaben am Anfang möglich und wird auch so gespeichert. Man muss die schon gespeicherte Aktion schon (mindestens) ein 2. Mal öffnen, um den Effekt zu sehen.

Ich kriege das Verhalten auch hin, wenn ich eine Aktion mit dem
Formatstring: %album%: %title%
kopiere (und sie dann gleich zum Bearbeiten geöffnet wird - nur dadurch ist es mir aufgefallen, da ich das Original in Kleinschreibung und die Kopie mit großen Anfangsbuchstaben vor der Nase habe).
Der Eingabefokus ist beim Kopieren übrigens auf "Quellformat", so dass eigentlich noch gar keine Bearbeitung des Formatstrings stattgefunden haben sollte.

Das setltsame Verhalten wäre dann nicht die Änderung der Schreibweise, sondern dass überhaupt bei einer Kopie und jeder weiteren Bearbeiten anscheinend in der Historie gegraben wird und ein sinngemäßer Ausdruck eingefügt wird.

So, Test:
ich habe den String mit den Großbuchstaben in den Feldern gelöscht und nun bleibt die Schrebweise gleich.
Ich füge den String mit der Großschreibung hinzu und kann nun den umgekehrten Fall beobachten:
der String mit der Großschreibung wird umgewandelt in einen mit Feldnamen in Kleinschreibung, da dieser String weiter oben in der Historie steht.

Also so ganz überraschungsfrei ist das nicht.

Der automatische Eingabefeld-Suchalgorithmus bietet aus der Historienliste einfach den nächst besten passenden alten Eintrag an, und so wie es wirkt, anscheinend "case-insensitive", ohne Beachtung der Groß-/Klein-Schreibweise.

DD.20170609.1144.CEST

Der ist ja auch hilfreich, wenn ich ihn denn benutzt hätte.
Das Einfügen eines Strings aus der Historie passiert zu einer Zeit, da war der EIngabefokus noch überhaupt nicht auf dem Eingabefeld, um ggf. eine Suche auszulösen.
Die sichtbare Änderung passiert in dem Moment, in dem ich auf den Kopieren-Knopf drücke und der Bearbeiten-Dialog geöffnet wird.
Das Feld mit dem Formatstring hat zu der Zeit noch nicht 1x den Fokus gehabt.
Und selbst wenn: die Nutzereingabe sollte heilig sein und nicht irgendwas eingefügt werden.

Da kann man mal sehen, wie der erste Eindruck täuschen kann.
Letztendlich ist das Thema komplett falsch benannt. Das hat nichts mit Doppelpunkt zu tun, sondern ist ein Problem von ähnlichen Eingaben bei Formatstrings.
Und die ersetzen einandern, je nach Position in der Eingabehistorie.

Ich war auf den Doppelpunkt gekommen, weil es in den vorigen Releases immer wieder Probleme mit Dateinamen und Pfadangaben gab u.a. mit dem Doppelpunkt.
Da war ich allerdings auf dem Holzweg.

Dass die Benutzereingabe beim Editieren ersetzt wird, finde ich immer noch gewöhnungsbedürftig.