Last month I reviewed these changes, indicating that it seems to me the boolean QOS_EMULATION_SQL attribute appears to be the only one of all these key/value attributes that we actually need.
Specifically, because T186673 hasn't been resolved yet, MediaWiki uses CACHE_NONE by default and we don't have a clear policy on whether it is better or worse to set the main cache to CACHE_DB vs nothing at all. My general impression is that for a small traffic wiki it probably helps to enable caching even if just using a local (non-sqlite) database. But there are is basically one major thing where we currently think it's worth explicitly avoiding use of the main cache if it happens to be configured to CACHE_DB, and that's the storing of revision text (SqlBlobStore). What we do there is we obtain the main cache (wrapped in WANCache) and ignore it if it's backed by a SQL database.
I was unable to find any current use of these attributes in our code bases.
Are these theoretical or current? For SessionBackend checking, do you mean that an extension that stores something in SessionBackend, would split its logic (beyond the documented requirements) and vary its behaviour at runtime based on whether the site administrator has configured a session backend that does vs doesn't support SYNC_WRITES? I note that the documented requirements currently state that SessionBackend (and by extent core more generally) expects SYNC_WRITES to be supported, so this would be at odds with that. If that is going to change, what kind extensions would you expect to use this and why?