To start with your last question: themeinfo isn't used anywhere. It is meant to store theme specific config, either for the theme itself, or for theme installers.
For example, say you have a theme that is available in 4 colours, then you could define those colours in the info file, so a theme installer controller could present them to the user for selection. The selected colour could then be written back to the theme knows in which colour it needs to be displayed.
You have an info file per theme, in the root of the theme folder, and there is no cascading involved, it's a single file that gets loaded.
And no, a theme is a folder, containing a collection of view files, which behaves exactly the same way as files in APPPATH/views.
The biggest differences:
for views the root path is fixed (APPPATH/views), for themes it's the active theme root
themes have an active and a fallback with cascading you can use an active to override for example only a single css file and re-use everything else from the fallback.
themes have build-in support for page templates and partials
The "use_modules" config key does several things. If set to true, it will enable the use of themes folder inside the module folder structure.
The use case behind it is: say you have an application that support theming as a feature. For example a CMS. And say you provide 10 themes for your CMS, and there are external parties that create themes to. Say also that your CMS has to option to install plugins that are written as Fuel modules.
Now, how would you make such a module work after installation? None of the existing themes know this module, none of them have the correct views.
When 'use_modules' is set to true, it introduces a themes folder in a module, so the module can provide either theme specific views ("this module supports theme A, B and C") or views for a default theme, so at least there is something to display after you have installed the module.
For an application where you control everything yourself, this functionality isn't really useful.
The second use is to assign a string to the key 'use_modules'. This does two things: - it uses this string as a path prefix - it activates the module name prefix
So, if it is set to true, and you load the view "index" from a "admin" module controller, it will load: - MODULES/admin/themes/<activetheme>/index - if not exist, THEMES/<activetheme>/admin/index - if not exist, THEMES/<activetheme>/index - if not exist, a standard view by the name "index" - "view not found"
If it is set to the string "test", it will load: - THEMES/<activetheme>/test/admin/index - if not exist, THEMES/<activetheme>/test/index - if not exist, a standard view by the name "index" - "view not found"
If it is set false, it will load: - THEMES/<activetheme>/index - if not exist, a standard view by the name "index" - "view not found"