Pass query arguments to fallback search on solr failure.

My biggest concern with doing this is cases where query arguments might be undesirable if they're passed on. Consider the case where solr fails on page 5. What if the fallback search doesn't have a page 5 of results? Or what if the filters argument means something different on the fallback search?

That's correct. Is there a case where apachesolr would be using the keys argument though? From search_view():

<?php
// Also try to pull search keywords out of the $_REQUEST variable to
// support old GET format of searches for existing links.
if (!$keys && !empty($_REQUEST['keys'])) {
  $keys = trim($_REQUEST['keys']);
}
?>

So if the apachesolr module isn't using the "old GET format of searches" I don't think we necessarily need to capture that value on failure.

In order to attempt to support older searches, we could pass the keys variable along as a $_GET argument... i.e.:

<?php
function apachesolr_failure($search_name, $querystring) {
// ...
drupal_goto('search/' . $search_info['path'] . '/' . drupal_encode_path($querystring), array('query' => array('keys' => $querystring)));
// ...
}
?>

My comment in #3 was incorrect. If $_GET['keys'] was being used against solr the core search module would translate that query argument to normal keys and would be correctly accessible in apachesolr_failure().

The only time we'd need to be concerned about keys is if the fallback search didn't support non keys query argument searches. I'm not sure handling this edge case in apachesolr is desirable since most fallback searches would work correctly with the normal search/SEARCH_PATH/SEARCH_KEYS method of searching.

If we remove keys from the list of query arguments we're interested in I think the original problems I raised in #1 are the biggest things we need to address before coding anything.