You're right, we don't expose that. Is this the type of thing you would just want to see logged (so that you could see it), or that you would need programmatic access to? If the latter, what would you use it for?
For the most part I think seeing it logged is enough, though there are a few use cases where programmatic access would be useful. We could, for example, enable/disable DVR UI when FMS server is detected as < 3.5. (Or even 3.5.3, if we want to be sure we're only using our setup/OSMF with what it's properly tested for). When using an edge network or CDN, you're not in control of the media servers directly. As CDN's roll out upgrades from 3.5.2 to 3.5.3 at the moment, they're not always forthright with when that actually happens. Others are farther back than even that. You may want to do special workarounds that are necessary with 3.5.2 that are not necessary with 3.5.3 for example. Or special workarounds that are necessary with 10.0 if paired with 3.5.2, for example.
If I was even greedier, I'd ask to know if it's on Windows or Linux, FMIS or not, or a Wowza server vs. FMS. I think that would require serverside scripts though to get to application.server.
Sounds like the change that would not impact the API would be to add a CONFIG::LOGGING in the NetNegotiator. But the examples above show that there may be reasons why a developer would want to have dynamic access through the API, perhaps ultimately through LoadState.READY.
Logged as FM-801.