I will need to write better documentation about it :-). This topic is a bit complex.
First, modules, libraries, product flavors & build types are extremely important for our Android Gradle plugin & Android library. With them, we can support any project, including those with dynamic modules and several libraries combined with different product flavors and build types, etc. As we decided to introduce the fully compatible solution, we also need the architecture to support it.
Basically, modules and libraries behave in a very similar way to files. They are mostly used to distinguish between the same paths/files placed inside different modules/libraries. Technically, you don’t need them at all if you provide the information in the path, but they are contained to allow high-level project organization.
Build types are also very similar to files and they may be useful for processing different sets of strings.
Product flavors allow for even more structured project organization as it’s a set of “tags” rather than just a name. This is particularly important for being able to pick the correct string based on the priority.
It’s important to understand that each combination means unique keys, so you can end up having a lot of strings with the same key but placed inside different modules, libraries, etc. It’s up to your code to use your strings correctly. We don’t recommend any particular way how it should work. E.q., our Android library is responsible for using the correct string based on the current flavor, module, etc. And your code needs to do the same. The logic is yours :-).
Anyway, you are right, it’s worth checking how we show this information in UI (@janbilek). We will have a look at it.