The Target Status & Configuration page shows the currently-loaded firmware - but not the currently-loaded OS version.
(it shows FW & OS versions required by the currently-loaded app - but not the OS present in the device)
What is called the OS is the ADL (static) library itself, which is linked with your application.
So the components listed in the Target Status view are not only the one “required” by your application (except for FW & DS information, which is more a “was built with” information); for libraries packages (OS & other libraries), the mentioned versions are the ones which are really linked (and let’s say “embedded”) with your app.
In other words, the OS itself is not present at all on the device out of the Open AT app binary. It is integrated in it.
Really? So what is the meaning/purpose of the separate “IntVersion” & “ExtVersion” values returned by AT+WOPEN=2:
When no app is loaded, AT+WOPEN=2 returns one version number - the “IntVersion” - so what does that one mean 
When an app is loaded, AT+WOPEN=2 returns two version numbers - “IntVersion” & “ExtVersion” - which may differ. So what do they mean
The “Ext Version” is related to the version of the library linked with you app. It’s almost the same information level that the OS listed in the Target Status view (parsed from ATI9 command).
About the “Int Version”, it’s not a really useful information. Let’s say that it represents the version of the Firmware interface which is internally used by the ADL library.
Isn’t it?
I had always understood that this was the OS version with which the installed FW was “compatible”
Which does sound like, “the OS version with which the installed FW is ‘compatible’”?
So, surely, this is a useful thing to know - in particular, that the “IntVersion” matches (or is “compatible with”) the “ExtVersion”
That was in Open AT early days.
Now that the interface is quite stabilized (Open AT OS is on V6.X since some years…), it trends to be not as useful as before.
Anyway, to be sure that you’re getting compatible versions, the official way is to verify they are both contained in the same Open AT Application Framework container package.
Even if it’s not a straightforward way, this is the guarantee that both packages have been validated together.