Für eine Begründung hilft es, mal per \displayMusic in die interne Struktur reinzuschauen. Erstmal nur Einzelnoten und Akkorde ohne Bögen:
\displayMusic { g a <g e> <a f> }
Für die Akkorde werden NoteEvents in EventChords gepackt (übrigens kann man das auch für Einzelnoten leicht erzwingen: <g> <a>).
\displayMusic { g( a) <g e>( <a f>) }
Hier wird in die EventChords noch ein SlurEvent noch mit reingepackt – da das gleiche für die Einzelnoten auch passiert, haben wir hier plötzlich auch EventChords (die zwar nur ein einziges NoteEvent, aber eben auch ein SlurEvent beinhalten).
An diesem Punkt müßte bei doubleSlurs also nicht einfach geschaut werden, ob wir einen Akkord haben (weil Akkorde, aber eben auch Einzelnoten mit Zusätzen gleichermaßen in EventChords gepackt werden), sondern die NoteEvents in jedem EventChord gezählt werden. Die context property doubleSlurs wird aber erst im Slur_engraver ausgewertet, der in der Datei lily/slur-engraver.cc, also in C++ geschrieben ist. Falls man überhaupt noch auf die verursachenden Events zugreifen kann in einem Engraver (weiß ich nicht, kenn mich mit Engravern nicht aus), dann müßte man wohl einen eigenen Engraver (in Scheme?) schreiben und den Slur_engraver durch diesen eigenen ersetzen.
Vielleicht hab ich was grundlegendes übersehen, aber es sieht so aus, als wär da so automagisch erstmal nicht viel zu machen. Ich würd mir hier mit ner Abkürzung behelfen:\version "2.19.56"
nods = \once \set doubleSlurs = ##f
\relative c'' {
\set doubleSlurs= ##t
< c e > ( < d f > )
\nods e ( f )
e ( f )
}