System L10n queries can be expensive, making it desirable to cache the responses.
However, we also want to be able to respond to changes to the system L10n settings, which we'll miss if we consult a cached value that predates the change.
This would require some mechanism, on each platform, for detecting when L10n settings have changed so as to trigger clearing the caches, for which QLocale would need to provide a static method.

We can then arrange for QLocale to take care of cacheing things it gets back from QSystemLocale::query() calls; it would then clear those caches (and trigger an updateSystemPrivate(), e.g. by instantiating a transient QSystemLocale instance) when the new mechanism alerts it to the need to change.
In so far as backends need to cache anything else internally, they can respond to QSystemLocale::query(QSystemLocale::LocaleChanged) by clearing that cached data; this happens during updateSystemPrivate().

There is an existing QEvent::LocaleChange emitted by platform integrations that are able to detect such changes, we could potentially hook into somehow. The logical place for that would be Q{Core|Gui)Application, having it connect a QLocale system-data cache refresh slot to the signal.

We should, separately, also consider having QLocale::setDefault() trigger emission of a signal.