Features created with "Allow conflicts to be added" do not actually export conflicted elements

In my experience conflicted Field Bases (field_base) and Field Instances (field_instance) are added correctly, but

1. Fieldgroup (field_group)
2. FlexSlider (flexslider_optionset)
3. Image styles (image)

are not. In my case the files related to the first 2,

• .field_group.inc
• .flexslider_default_preset.inc

were not present and were not created when I generated or downloaded the feature.

Conflicting Views and Strongarm elements aren't exported either. It looks like anything that uses the hook_whatever_api plugin structure doesn't export conflicts.

Still investigating...

I thought this through a little more, and basically the problem is that only Features has a way to deal with conflicts. Ctools, Views, Strongarm, etc do not. If you have two modules that define the same View, Views does not have a system to show that to the administrator and let them decide which version to use.

So this is actually probably a problem for those various contributed modules.

#3: this might sort out by module weight, but did not check the code for that.

debugged this a bit by selecting a conflicting and a nonconflicting rule. looks like the problem is in features_populate(), it gets both rules and spits out only one.

It looks like in _features_populate()

    if (!empty($data) && $function = features_hook($component, 'features_export')) {
      // Pass module-specific data and export array.
      // We don't use features_invoke() here since we need to pass $export by reference.
      $more = $function($data, $export, $module_name, $component);

this calls e.g. entity_features_export() which delegates to \RulesFeaturesController::export() which only spits out DB content.

Of course we could take features_get_default($component) and trick it into $export, but we had to duplicate dependency handling of the export controller.

EDIT: I came to this by debugging and it looked like that features hook got an "order" for the conflicting elements but did not serve them (tested with rules that uses said entity controller)

This is a showstopper to use features with defaults like from commerce, so raising prio.
(Maybe it's a dup but couldn't find.)

TO clarify some findings and guessings:
* Gues this bug DOES happen with Entity API exportables (tested rules using RulesFeaturesController, as well as message type using EntityDefaultFeaturesController)
* Gues this bug DOES happen with Ctools exportables (tested with views)
* Gues this bug DOES NOT happen with Faux exportables (tested with field bases)

If the bug happens, the object is not written to hook and not in info file.

This bug happens with features conflicts (marked red by features) as well as other code defaults (maybe from commerce) which leads to user selections silently and unexpectedly dropped.

The called functions are
* ctools_features_export
* entity_features_export() => EntityDefaultFeaturesController->export()
** RulesFeaturesController
** also: PaymentMethodFeaturesController

Made a plan in the summary.

Patch flying in that might fix the issue for our hooks.
It looks heavier than it is, because ripping out conditions changes indentation.

Also added child issues in the other projects.

I can confirm this patch does what it announces on all 25 component types on my system (this includes test of the crosslinked entity patch, but not og).

Patch #9 is working for me.

I think this patch needs to actually check the value of the "Allow conflicts" option before doing all of this. This is such a heavy change that I really worry about it for normal users. For example, if Allow Conflicts is disabled, you *want* the behavior that adds dependencies rather than exporting the conflicting config.

For example, people using Features via Drush are not going to expect this large change in how stuff is exported.

(Also, this is far from a "critical" issue)

The patch in #9 also worked for me. It allowed me to refactor a module and resolve conflicts manually, breaking it up into simpler component modules.