Die Fehler-Situation war eine Exception im XStream/CGLIB. Sowohl der POM-Editor, die Eclipse „Maven-Dependencies“ und auch sonst zeigten XStream 1.3 an, wie man es erwarten konnte.
Im POM für Projekt A ist XStream 1.3 als Abhängigkeit eingetragen. A hängt noch von B ab, in welchem XStream 1.2.2 eingetragen ist. Der Dependency-Eintrag im POM von A enthält einen entsprechenden Exclude auf XStream aus B. Soweit so gut.

Wenn man nun aber in Eclipse und dem „Maven Integration for Eclipse“-PlugIn die „Workspace Resolution“ eingeschaltet hat, dann kann es passieren, das über diesen Bypass ein zweites XStream in den Classpath wandert. Das kostet dann Zeit, weil es auf dem einen Eclipse-Helios-Workspace geht und auf dem anderen nicht. Das macht sich beim Kunden besonders schlecht, wenn man für das Deployment einen solchen Workspace benutzt (wie bei mir geschehen) und Stunden benötigt, auf das Problem zu kommen.

Ich tendiere immer mehr dazu, dass man mit Maven einen festen überprüfbaren Abhängigkeitsbaum initial erzeugt und diesen dann fest in das Projekt einbindet. Sollten neue Abhängigkeiten nötig werden, so geht man wieder diesen Weg: get dependencies, test it and freeze.