We're aiming at supporting minifying and compiling out of the box. Not sure if anything other than CSS and JS will be supported out of the box but implementing any compiling routing should be relatively straightforward. Note that this part if Yii2 isn't even in alpha state so it can be changed still.

This is very good feature. I have an implementation which is close to what you planning, so I can think it can be useful to describe it. Also at the end are some thoughts on your design and some suggestions.

Current features:
1. No "random" registerScriptFile() calls - use packages only (extensions still use registerScriptFile() calls, but this is ignored)
2. Package can have "baseUrl" (url on the server, for js/css from public folder) or "basePath" (assets inside the protected folder, should be published first)
3. Package can contain both js and css (better not to do this, see below)
4. Only one package can be registered (see explanation below)
5. Scripts like jquery can be included from the google CDN ('useGoogleScripts' setting in the config)
6. Depending on the config settings we can keep full js/css or automatically minify them (I use modified minscript (http://www.yiiframew...sion/minscript/) extension for this)
7. There are dependencies and packages can include other packages.

Bonus feature (not related to packages) - special implementation of beginScript / endScript, so the js code in a view can be added like this:

What can be improved/changed in my implementation:
* Point (3) - "package can have both js and css" - this is probably not good and it is better to have separate packages with js/ts/css/less. We can specify 'type' for each package and based on the type we can know how to process this package (compress and join or compile first and then join, etc).
* Point (4) - only one package can be registered - this limitation was initially implemented by intention. When scripts are minified then the page contains only one combined js and one css. But now I think it is better to remove it and allow to register additional packages, so the page can contain more then one combined js or css (this is useful in some cases).
* Point (6) - now packages can only be minified on-the-fly and it is better to have also a console command to generate minified packages off-line.

1) Separate package handling logic (packages description and registration) from the build process.
Now I see 'process' keys in the packages configuration and it would be better to remove it.
Instead we can have some 'type' or 'processor' key which will point to the builder object class. So we can have different builders like JSBuilder (compress and glue js), CSSBuilder (compress and glue css), LESSBuilder (complie less and then compress and glue), etc. Builders can then be used to do on-the-fly or offline package compilation.
2) How to deal with gluing of js / css files. I think the most simple way is to build each package independently, taking into account dependencies. Then we can include into the web page one meta-package which depends on all other packages or include individual packages.
3) Allow to easily switch between compressed and non-compressed scripts
4) Allow to use scripts both from public folder (no need to publish then to assets) and from the protected folder (publish to assets)
5) Consider adding a support for scripts inclusion from google CDN. It would be good to have an option to easily switch from local versions to CDN.

1. What if I want to use Google closure with extreme optimizations for package X but with normal optimizations for package Y?

Then we just specify different processors for these packages.
Basically the idea is to specify processor class or class+params instead of callback.
This also means that we need to have files of the same type for one package, so the structure will be:

Here if we can specify '*.js' then it should be also possible to specify individual scripts like 'one.js', yes?
Also will '*.js' be recursive (if there are subfolders below the app/scripts)?

So I think it is better to have packages for files of the same type. By default package will include all appropriate files from the 'basePath'.
We can also allow to specify individual files to include or constructs like '*' and '**' to include all files / recursively include all files. But this is optional and can be postponed - the developer can create appropriate folders structure, so one package = one folder + other packages as dependencies (or just dependencies).
And the 'map' parameter should go to processor configuration:

Ah. I thought you're talking about what's at github. We've decided to use processor classes instead of callbacks.

Actually yes, this is about what at the github. Sorry, I didn't read the full discussion and thought that description at the top is up-to-date.
It is not completely clear how processors will be implemented - will we have something like ComplieLessToCssAndCompressProcessor or will be able to apply two processors (CompileLessProcessor and CompressCssProcessor)?