Frei nach dem Motto "Composition over Inheritance" könnte man den StateManager auch weglassen. Stattdessen könnte es eine Datenstruktur geben, die das UI beschreibt. (Diese Bereiche mit dieser Positionierung gibt es, in denen diese Elemente liegen, die wiederum auf jene Art angeordnet werden. Der Button hier löst diesen Effekt aus und der andere hier jenen Effekt. ...) Es wird nur gespeichert, welche UI-Elemente gerade vorhanden sind und es können andere aktiviert und deaktiviert bzw. geladen und entladen werden.
Wenn man also ein Objekt hat, welches sich um alle UI-Elemente kümmert (Prüfung der Benutzerinteraktionen mit dem UI, ausführen der Event-Listener, ...), könnte man mit der gleichen Schnittstelle (Update, Render) auch ein Objekt besitzen, welches alle Ingame-Objekte handhabt. Letzteres würde wissen, ob es gerade "aktiv" ist (das Spiel läuft) und alle Ingame-Objekte aktualisieren muss oder ob es "inaktiv" ist (Hauptmenü) und somit rumidlet.
Will man darauf aufbauend für das UI States implementieren, dann würden alle States instanzen der gleichen Klasse sein, da alle lediglich die anzuzeigenden UI-Elemente besitzen.
Will man möglichst "Data Driven" arbeiten, würde man für die UI-Elemente nicht den auszuführenden Code (also den jeweiligen Callback) definieren, sondern daus aufzurufende Menü bzw. die Information "Spiel starten", "Spiel beenden" etc.