Aggregated CSS/JS file names, when regenerated? What triggers the aggregated/compressed CSS/JS file names to be regenerated?

Because of the default header for .css and .js set in Drupal's stock .htaccess is 2 weeks, this causes issues with Varnish which obviously just obeys the headers it receives from the application.

Caching .css/.js for 2 weeks isn't really necessary, our web servers can serve hundreds of requests for static files per second. It's the Drupal requests that always worry me. So I can change the .htaccess (though I actually override the Cache-control: max-age header in Varnish so we don't have to modify stock files provided by Drupal).

I have noticed that regeneration can sometimes can be triggered with a drush cc css-js but possibly only if the aggregated files are over a certain age.
Does anyone know what the logic is behind this?

Rather than overriding the header sent by Drupal, it would be useful to know when the file names are regenerated, because that's obviously a way of making sure that HTML code cached in Varnish is picking up a new set of CSS/JS files.
You're looking for drupal_build_css_cache &amp; drupal_build_js_cache. The building happens when the file doesn't exist or when the combination of files used in the aggregate is different than before.

Looking at drupal_clear_css_cache &amp; drupal_clear_js_cache the variable gets removed &amp; any file older than 30 days gets deleted. By removing the variable, drupal will then check to see if the contents of the file has changed, if yes a new aggregate will be built. So the file name is built by using a hash of the files content and the quick lookup is built by a hash of the file names used.

If you want something that's a little smarter than core, doesn't cause a stamped of writes to the variables table on a cache clear, and keeps files around based upon usage instead of a 30 day window give Advanced CSS/JS Aggregation a try.