Full absolute url is returned to core JS aggregation, requiring HTTP request to aggregate file contents

I have found something that is causing delays in core JS aggregation, but it also has the look of something that might have been a workaround for some other bug, so I'm putting this here for review:

function javascript_libraries_cache($uri, $sync_cached_file = FALSE) {
  ... grab file, save it ...

  // Return the local JS file path.
  return file_create_url($file_destination);
}

The comment states that it returns the local file path, but actually returns a full absolute url - an absolute url to a local file (because its been cached by javascript_libraries locally already)

I found this from one of its symptoms while debugging aggregation: what happens is, during core aggregation, javascript_libraries_cache here returns a full url which means that core aggregation has to pull this over the web. This adds an HTTP request for every javascript_libraries file during aggregation, which may or may not go over the web or local net, depending on your setup. I can't see a good reason why this would return an absolute url to a local file here, but I may be missing some history.

The only files that I've observed during core aggregation that get full urls this way are coming from javascript_libraries (but it would also happen if a module or theme specified a remote file, which would be a valid way to cache it, but the preferred way would be cache locally in javascript_libraries first)

I've tested just returning $file_destination instead, per attached patch (it's a proper stream uri, so should work under most circumstances) and it works for me under the following conditions:

• using no aggregation, so javascript_libraries files (local and remote) are inserted as urls. works because drupal_get_js adds its own file_create_url
• using aggregation + remote file (a separate local test site hosts the JS)
• using aggregation + local file (uploaded to javascript_libraries on the test site)