Dobra chyba wiem już o co pytasz.

Ja jestem zdania by rozwiązania były tak proste jak to tylko możliwe
(jednak zapewniające osiągnięcie celu). W tym przypadku poleciłbym
zastosowanie wzorca singleton który by zawierał wszystkie opcje programu
w czasie wykonania. Te opcje to hasz wartości. Ten singleton by miał
taki niestandardowy ficzer jak wewnętrzną listę zbiorów opcji (tych
haszów). Na samym początku listy był by hasz opcji wciąganych z pliku
konfiguracji. Natomiast specjalne klasy okien (rozpoczynające nowy
kontekst) wywoływały by na tym singletonie opcji metodę options.clone()
i np. options.setShortDataFormat("format ze skrótem dnia tygodnia").
Operacja clone powodowała by dodanie do wewnętrznej listy obiektu
options nowego pustego hasza. Natomiast options.setShortDataFormat
ustawiałby jedną zmienną w tym nowym haszu. Dostęp do pozostałych opcji
by następował przez przejście od końca listy do jej początku i zwrot
pierwszej napotkanej wartości.

To w sytuacji gdy jest jedna hierarchia okien i tylko jeden aktywny
kontekst. Jest to zdrowe dla użytkownika więc chyba ten pomysł powinien
wystarczyć (inaczej trzeba by stosować drzewo opcji zamiast tej
proponowanej listy).

Zaletą tego rozwiązania z singletonem jest fakt, że program staje się
modularny - opcje stoją z boku. Natomiast włączanie silnika opcji w
klasy poszczególnych okien (rejestr opcji w każdym oknie i
przeszukiwanie w górę hierarchii okien) jest moim zdaniem mataczeniem.
Choć było by to potencjalne rozwiązanie dla przypadku gdy jest wiele
hierarchii okien w programie.