WidgetFactory is dropped and replaced with global configuration of all classes (i.e., widgets and other non-widget classes can be globally configured like in 1.1)

Theming is now done by replacing path prefixes. This allows theming both view names and view files. For example, if "/home/qiang/test.php" needs to be themed, and the theme has a path map "/home/qiang" => "/home/schmunk", then the themed version would be "/home/schmunk/test.php".

I looked at your multi-theme extension. It may be useful in a setup that mixes backend and frontend. In a setup like described below, this is not needed: http://www.yiiframew...ii-project-site

Recently I have found kind'a creative use for themes, we use a theme as a website packing all the js, css and image resources into a theme and pusblishing it. We also use a directory in controllers dir named the same as the theme and are setting controller path like controllers/theme_name based on theme set in configuration.
Personally I would like this functionality expanded a little. Also to make full use of this functionality, I want the ability to set multiple directories for controllers

@Qiang: My use case is the following: I include a module (eg. yii-user) via composer and I have to change the theme for that module, because - let's say my default (frontend) theme has been completely changed, but I don't want to change the code in the module itself.

Can I overwrite the theme for that module - partially for some controller actions or even views - with the global configuration?
Or do I have to stick with something like the current theme manager replacement?

Because the new theme implementation is based on path mapping, you may theme whatever files, provided you know the source file paths.
For your particular example, you could add a path map like: '@yii-user/views' => '@webroot/themes/mytheme/yii-user', and you can then customize the view files and resource files for the module.

I have always (slightly) ajusted the theme directory: my theme directory contains the public files and directories (like it does now) but also a 'protected' directory which contains a directory 'views' (speaks for itself) and a directory 'widgets' which contains the theme-specific widgets.

Use case:
My default view files contain, for example, a widget @widgets.CBreadcrumbs. What my custom Controller does is first look in <theme>.protected.widgets if the widget exists. If it does that's the widget that's used. If it does not exist, it looks for the widget in the webroot.protected.widgets (i.e. <theme> is replaced by 'webroot') and uses the widget found there.
I guess its clear that the default CBreadcrumb contains all the functionality required but uses a different representation from that of, say, Bootstrap. This way I don't need to create a theme specific viewfile just to include a widget with a similar API but different representation.
I'm not quite sure if this results in the same functionality as the yii2 path mapping.

In addition to this my <theme>/protected directory also may contain a class file Theme (class Theme extends CTheme). If this theme-specific Theme class exists it is used by the themeManager to represent this theme. I mainly use this feature to set a (user specific) color which is used to compile the less files into css files and sometimes to configure portlet containers.

Finally I define the path alias 'theme' when a theme is set. Obviously it points the the /themes/myTheme path.