Anyway, without anything else to do I've devoted most of my spare time to the game. I've come up with a design for a system which encapsulates all input, timing and state changes within the game. The design centralizes around the State class which as the name implies represents one state in the game. As an example the gameplay screen is one state, and the main menu is another one. Every state has its own content, its own rules for how it receives and interprets input and also its own local time.
The states are handled by a StateManager class which keeps a stack of top level states where only the topmost state is updated. Once a state is popped from the stack the one below gets attention. When the last state is popped the program automatically terminates. This way a state only has to worry about itself and its own termination which makes it very easy to track changes in the game. States have no access to other states and can therefore do no harm to them. A simple scenario would be a state stack with a MainMenuState at the bottom and a GameplayState on top of it. When the player chooses to end the game the GameplayState terminates, which automatically drops focus down to the MainMenuState. Then the player can choose to create a new GameplayState on top of the main menu, by pressing the New Game button. On the other hand the player could press the Exit button which would terminate the MainMenuState, which in turn would exit the program since it was the last state in the stack.
A state is also allowed to contain any number of child states. An example would be the LoadGameSate which belongs to the MainMenuState. LoadGameState is not a top level state since it is present within the main menu with the main menu still visible behind it. A top level state must be completely independent of other top level states, so this kind of load game box could not be top level.
Every frame the StateManager gathers input, distributes input among the states, looks up time and updates all states according to input and time. This way all that is left to do every frame after the StateManager is done, is to gather graphic data from the StateManager and send it to the graphics system for drawing. Nice and separated.
As a side note, within this design with the data (States) and the graphics completely separated from each other, one could imagine a scenario where the graphic engine for some reason failed and shut down, and where instead of shutting down the program the game simply "rebooted" the graphics engine and started off again where it ended. That would be nice.
Right now I don't have working scenario with mulitple states present in the game so the next task will be to produce one. Nothing fancy, just something to see that practice actually follows theory.