Sorry for having to start this discussion again... Sadly, it's not working right!

The problems it runs into are the same we have with drupal_alter() and the fact that themes aren't modules. Let me explain... Whenever we are on the backend (even when we are on the theme settings page of a particular theme) we will not invoke the alter hooks for that theme. Neither will we invoke the libraries info hook for themes as introduced by this patch.

This is because a) global $theme is always the theme we are actually rendering (not the theme we are displaying the theme settings for... there are actually other related issues/bugs in Core already that show this pretty well... anyways...) and b) even if we switched to global $theme_key it would not fix it because whenever we build the cache for the libraries and happen to be in the backend (other than the theme settings page) it will still ignore the front-end theme.

So... What we really need is for this lookup to be completely agnostic of the active theme. We have to loop over all themes and their base themes regardless of whether they are active or not. Also, we should add a $type key to the info array somewhere so we know whether the origin is a module or a theme... Or something else that gives us that particular information.

I am filing this as a bug report because even though it doesn't break anything it simply doesn't work the way it was supposed to work.

It has nothing to do with that. I don't want to use it with disabled or inactive themes, you missed my point ;). The problem is this: If you have an admin theme on your page and you clear the cache while in the backend it will then, when reloading the page, rebuild the cache (module cache + admin theme, because the admin theme is active at that point). But... by doing so, populates the cache with the libraries declared in the admin theme. Now, when you leave the backend, the frontend theme will not be able to load it's libraries because they simply aren't in the cache.

Or, think about the themekey or switchtheme modules. Their libraries won't, ever, get their libraries registered. Unless, of course, the cache is empty in which case, however, the other theme won't get it's libraries registered. Hence, we need to either split up the libraries registry and provide both, a theme libraries registry and a module libraries registry (in separate) and merge them when loading the page or cache the entire registry together but by adding the theme key of the active theme to the cache key.

I'd like for some more people to test this in the wild and then release a new version pretty soon. Since we announced theme support with the last version, but it's not really working, we should get this out soon.

Awesome thanks for the update. There's one BC-break that we have currently relative to 7.x-2.1, which is very minor, but which I've sort of come around trying to avoid. So it might still be a week or two until the next release. I hope it's going to be earlier, just wanted to give a heads up.

In v2.1, we were able to declare hook_libraries_info() in our base theme and use it with libraries_detect/libraries_load in our subthemes, even when the base theme is 'disabled.' In v2.2, our base theme must now be 'enabled' in order for its hook_libraries_info() declaration to be made available to its subtheme. It's not a huge issue, but it is certainly worth noting for folks using a similar structure.