export of language_default variable is broken (& any other variables which store an object)

The language_default variable is stored in the {variable} table as an array.

However, if this is set per-realm and exported as part of a variable_store Features export, the result is an array:

/**
 * Implements hook_variable_realm_default_variables().
 */
function myfeature_variable_realm_default_variables() {
  $realm_variables = array();
  $realm_variables['domain']['mydomain'] = array(
  'admin_theme' => 'seven',
  'anonymous' => 'Anonymous',
  'date_default_timezone' => 'Europe/London',
  'language_default' => array(
    'language' => 'pt-br',
    'name' => 'Portuguese, Brazil',
    'native' => 'Português',
    'direction' => 0,
    'enabled' => 1,
    'plurals' => 2,
    'formula' => '($n!=1)',
    'domain' => '',
    'prefix' => 'pt-br',
    'weight' => 0,
    'javascript' => 'pEuv3q13tcp6nQ7IbfdMXmPXgPiApU9DSamV9vgR_HY',
  ),

If the feature is then reverted, the value in the variable_store table is set to an array, which then breaks Drupal core's language system: the array is not recognized as a valid language and no multilingual features are available.

The problem is caused by variable_realm_features_export_render() using features_var_export() to write the export code, which in turn casts all objects to arrays:

  if (is_object($var)) {
    $output = method_exists($var, 'export') ? $var->export() : features_var_export((array) $var, '', FALSE, $count+1);
  }

Using ctools_var_export() instead fixes the problem. That adds an unrelated change, as it quotes numeric values, but that won't cause a problem with variable values. I'll file a patch for CTools for that anyway.