Exported DS configs do not include custom styles.

It seems that Display Suite provide 2 different types of export. Once contains the implementation of hook_ds_field_settings_info() and the other contains hook_ds_layout_settings_info().

They are both titled as 'Display suite' in the features admin interface when creating a feature. It's pretty confusing a we have no idea which one we need, or what the difference is between the two. Perhaps they should be called 'Display Suite Fields' and 'Display Suite Settings'?

Yes, they styles do get included if you include both of the exports for your content type that are provided by Display Suite. However, what doesn't get included is the actual list of styles, but thats because they are stored in a system variable, so I was able to include them manually with strongarm.

I just found a way to do this whilst working on exportable support for the Bean module. See #1160056: Make Bean types exportable specifically my notes in http://drupal.org/node/1160056#comment-4623828

You need to implement hook_features_api to override the default CTools implementation.

Ah, ok I forgot to include the features.inc file in my patch. Although, nothing in there is relevant to this at all - it only contained an implementation of hook_features_pipe_MODULE_alter(). The only bit relevant to this the following where features.ctools.inc's default hook_features_api implementation is overridden to provide a name that differs from the module name.

/**
 * Implements hook_features_api().
 */
function bean_admin_ui_features_api() {
  return array(
    'bean_type' => array(
      'name' => t('Bean types'),
      'feature_source' => TRUE,
      //'default_hook' => 'bean_type_default_types', // We don't have a default type implementation yet
  		'file' => drupal_get_path('module', 'bean_admin_ui') .'/includes/features.inc',
    ),
  );
}

Please don't mark this as won't fix. It's really bad UX at the moment as in the features admin ui you have two items named identically which is very confusing. Features prvides the ability to override the default CTools hooks for exactly this reason - so that you can customize them if need be. hook_features_api is a very basic hook with only about 8 lines of code that returns an array. You could even call the default hook implementation in your code to get the default array as returned by features.ctools.inc and then just override the 'name' key. Something like

/**
 * Implements hook_features_api().
 */
function mymodule_admin_ui_features_api() {
  $api = ctools_component_features_api('mymodule');
  $api['name'] = t('My Custom name');
  return $api;
}

I like your idea about patching features to support custom naming out of the box though.

Yeah, that seems t do the job. Nice one.