Ich denke, die Programmierenden hatten diese Aufgabenstellung:
(1) Beim Aktivieren der RESUME-Funktion (kleiner Hebel links unter dem Blinkerhebel):
=> (1.a) aktiviere (p)ACC,
- wenn dabei bisher noch keine Geschwindigkeit in der Soll-Anzeige steht, nimm die aktuelle IST-Geschwindigkeit,
- wenn dabei bereits eine Geschwindigkeit in der Soll-Anzeige steht (egal ob manuell gesetzt oder vom pACC), nimm diese.
(2) Beim Aktivieren des TravelAssist (Taste rechts oben auf dem Lenkrad):
=> (2.a) aktiviere (p)ACC und
=> (2.b) aktiviere TravelAssist
Da Programmierende nicht immer Nutzende sind, kommt es immer wieder zu Lösungen, die aus Sicht der Programmierenden logisch erscheint, aus Sicht der Nutzenden aber überhaupt nicht logisch sind. Und so einen Fall haben wir nun hier:
(A) Wir Nutzende wünschen uns meist, dass sich (2.a) nicht von (1.a) unterscheiden soll. Es soll also egal sein, ob (p)ACC über RESUME (1.a) oder TravelAssist (2.a) eingeschaltet wird.
(B) Die Programmierenden könnten stattdessen argumentieren, dass ja nicht klar sei, welche Soll-Geschwindigkeit der Nutzende beim Aktivieren des TravelAssist haben möchte:
- die im Moment gefahrene Ist-Geschwindigkeit?
- die im (p)ACC stehende Soll-Geschwindigkeit - unabhängig von der tatsächlich gefahrenen Ist-Geschwindigkeit.
Und dann kommt es zu der Logik, wie wir sie derzeit haben:
Der TravelAssist geht immer auf die sichere Seite:
(i) Ist keine Soll-Geschwindigkeit aktiviert, wird die beim Aktivieren des TravelAssist tatsächlich gefahrene Ist-Geschwindigkeit genommen.
(ii) Ist eine Soll-Geschwindigkeit aktiviert, wird diese beim Aktivieren des TravelAssist genommen, weil sie bewusster Wille der fahrenden Person ist — daher hat diese auch die Soll-Geschwindigkeit zuvor explizit zu aktivieren.
Ich habe in meinem Berufsleben bereits unzählige solcher Diskussionen mit Programmierenden gehabt, manchmal gelang es, sie von der Praxis zu überzeugen, manchmal nicht. Ich bin gespannt, was hier passieren wird - ich vermute: nichts.