When Django processes a static file (either a .css file that was already

in the tree, or one that was compiled from a .less file), it will look

for certain references to other static files, through calls to @import

or url(...). It then attempts to load these in to generate a suitable

path to a version with a hash in the filename. The assumption it makes

is that this referenced static file lives in the same static storage as

the file referencing it, which is a bad assumption for extensions.
We now have a custom storage for static files that tries to determine if

the file referenced is in a different storage. If so, that storage is

used to compute the path. Otherwise, it falls back on the standard logic

of checking the parent file's storage.
This shouldn't require any changes to extensions, particularly since

they weren't working before in this regard.
The one change that may impact .less files doing something funky is that

@{STATIC_ROOT} is no longer blank when packaging, and the include paths

no longer include the static/ directory. If extensions were properly

using @{STATIC_ROOT} for all .less file references, then this won't

break anything. References to other files, like image backgrounds in

stylesheets, can now use @{STATIC_ROOT} as well and expect a proper path

back.
One important note is that we have no way of generating paths that are

relative to the root of the application. For subdirectory installs,

these paths are not going to be correct. It's pretty important that

sites host on the top of their domain instead.

Modified rbmotd to reference header_bg.png in Djblets, and tried building

it. Prior to this change, it would fail, being unable to look up the path

in a different app. After this change, it succeeded, generating the correct

URL in the CSS file.
Unit tests pass.