At present the macOS backend for QSystemLocale implements fallbackUiLocale() in terms of some environment variables, falling back to getting data off the object returned by CFLocaleCopyCurrent(), and its query() doesn't implement the LanguageId, ScriptId or CountryId queries.
The QLocale::system() object is initialized from the CLDR-derived data for the fallbackUiLocale() before over-riding some of that data with results from query(), so it gets its language, script and country from the environment variables (if set, which they typically are) via the usual QLocale look-up, via CLDR's likely sub-tag rules for falling back, if the locale named by the environment variable isn't one CLDR supports.
So the language, script and country reported by QLocale::system() are derived from environment variables, potentially via the likely sub-tag lookup.

However, everything that the macOS backend does implement in query() is based on the actual system locale, which may be quite different from the one named in the environment variables. This leads to confusing results, e.g. QLocale::system() claiming to be en_US but actually doing its number formatting wildly differently than en_US.
We should be consistent and have the macOS backend use the language, script and country of CFLocaleCopyCurrent(), so that its name() is consistent with its behaviour.