LO 7.4
Style Inspector seems to consider not all formatting layers while presenting its output to user. E.g. list style is not present in view of formatting stack of paragraph under investigation. Similarly global settings layer apparently not foreseen to be presented for given paragraph.
It results from it that if document Author needs to know/see all formatting layers, for given paragraph, it needs to additionally take a look in few other corners than just SI.
Is this proper conclusion?
I see the list style named under Paragraph Direct Format. I guess it is there because it overrides the paragraph style. Even ad hoc lists such as those produced by Shift+F12 get a name, although in that case it is an 11 digit number. Tested in 7.3.7.2 & 7.5.5.1
ListStyleInStyleInspector.odt (29.0 KB)
I understand that presentation of list style is property, a setting within paragraph style, eventually withing paragraph direct formatting. It is not the same as list style acting as one of formatting configuration layers.
Currently I can see, for certain quite simple template, four layers be presented in style inspector view:
Some of them are blank, blank but presented.
The inability to report correctly list style application is one of the current Inspector limitations. I already filed a bug report about it, tdf#142190. Add a comment to it, this will show users are interested in its resolution.
Yes. There are lots things to do with style inspector, like nested character styles support, complex property support, list style support, graphical objects support, ability to not only view, but edit… It is something needing much love.
The question is rather if style inspector isn’t really intended to include global settings and list style layers in its view. Eventually there are more layers of formatting settings not covered in SI view by design than those two.
The style inspector is relatively new in LO development history. It has not yet reached full maturity but it already brings a lot of valuable information even if we all wish more with improved accuracy. The best thing you can do is to file Feature Requests on Bugzilla with a good specification, rationale and use case. You’ll get developers feedback about it in return and this will also certainly encourage the present developer to perseverate.
Note that I already answered your question. I mentored the GSoC student that implemented it after my proposal, so I do know what is intended to be there 
- and all that I mentioned, and more, is in the list.