=== #page-mod-forum-index ===
=== .path-course .path-blog ===
Very useful for core subsystems because you may address anything in /course/* , /blog/* easily.
=== plugins ===
I do not like the wrapping of forum stuff in .path-mod-forum because we do not want to say this comes from this directory, but we really want to say this is part of forum. In case of chat we have the problem with subdirectories, it could be solved by adding all parent paths to each page.
All plugins are defined in get_plugin_types() - that is the only place we need to modify when you are adding new type o plugin - it returns array (plugintype=>plugindirectory), the $component name is constructed as $plugintype.'_'.$pluginname. The rest of functions in moodle accept either $component or $plugintype + $pluginname. There is no place that would accept the path as defined in the CSS class, everything is now using the standardised plugin names (get_string(), install, upgrade, db tables, ... ... ... ... ...). Sometimes unfortunately the plugin name is very different from the actual location, the main reason is that we have a limit on the length of DB tables dues to oracle legacy.
I do not think theme designers actually care how we call the classes - they can see them there without any problems. The problem is that the PHP developers write the first CSS and have to wrap the divs withs classes around the code - so the argument that it is confusing is invalid because all developers have to use get_string() and friends which require component name.
So still ".mod_forum" or better ".plugin-mod_forum" makes much more sense to me.