Error when enabling a 'core' feature on a new site

This error is expected. Like any module, a feature module cannot be enabled if it provides any configuration item that already exists on the site.

Can the type of configuration in 'core' only be used if you package your features into a custom installation profile?

That's probably the easiest way to go. An alternative might be to tweak the configuration options of the "Exclude" package assignment plugin to produce a feature set that would exclude configuration provided by the install profile you used.

Also, if the Features module is enabled on the site, it will allow config that already exists to be imported. Marking this as answered.

Re-opening issue because this question might be "answered" as to why the workflow is crashing; but #2 and #3 does not remedy users of features module when they are enabling a feature module through drush... and it crashes.

I understand that the features module scope does not deal with config override; and it is of opinion that config override is to be handled at a future build of features_override. Perhaps a path to move forward would be to prevent fatal crash when there is config override conflicts, ignore these conflicts, and not crash the drush enable process.

Screenshot provided that config override conflicts trigger a crash.

see previous comment why this issue is set back to "active"

I don't think this is an issue in Features. In your error message above it is referencing the UUID of the config. When config is exported to a Feature, the UUID is removed. So the module you are importing with the overriding config wasn't generated with Features.

I cannot reproduce any problem enabling a proper Feature module on a new site that has Features enabled. It allows the existing configuration to be overridden as expected. So you'll need to post a step-by-step procedure for reproducing this.

Also, use the new beta8 since there were many fixes in the past few days.

Perhaps you are right, the feature module was created about a month ago using 8.x-3.0-beta6. The core configurations like node.type.article.yml , taxonomy.vocabulary.tags.yml , were modified and added to a feature module. I am using today's feature dev module through git.. (using latest commits) and I've enabled the feature module in a clean drupal 8 install. During the drush enable process , it crashes out and does not enable the feature module because it does not like some of the active configurations (node.type.article.yml , taxonomy.vocabulary.tags.yml) inside the feature module.

Summary :
a.) Using 8.x-3.0-beta6 created feature module that contains new node types and existing node like node_article and vocabulary_tags .
b.) Clean drupal install and using latest commit today feature module, i've enabled feature module and encountered a crash.

Are you saying that if I created the feature module using latest feature commit that contains new node types and existing node like node_article and vocabulary_tags; then enabling feature module in a clean drupal install will not resolve in a crash?

The error message in #4 is not an error in features but rather (as I noted earlier) the expected outcome. Core prevents you from installing any module - Features-produced or otherwise - that provides configuration that is already on the site. In this case, you are attempting to enable a (feature) module that provides configuration that's already on the site, because, presumably, you installed with the Standard install profile, which provides the configuration that your feature also provides.

If you want to be able to install your feature on a new site, you can use the option that allows you to produce an install profile along with your set of features. The install profile will not include any configuration you've assigned to other features, so you will be able to install a new site with that install profile and then enable your feature(s) on the site.

Hope that helps. If so, please move this issue back to Fixed.

@nedjo
Your saying that this is a feature and not a bug. Fair enough, core made a decision to crash a process instead of proceeding the process. I would like to assert that our community (drupal 7.x) expects modules not crashing when enabling a module, and furthermore an extension (contrib) would override an initial configuration state.
So having said that, if core introduces a configuration state through profile; there is an expectation that a custom module can override an existing core configuration state.

Please confirm that this workflow is obsolete in features 8.x

@chriscalip:

Correct: in Drupal 8 you cannot re-provide a piece of configuration that is already on the site (for example, because it was already provided by an installed extension). What Drupal 8 does allow is overriding configuration in an install profile.

There are a few ways we try to support work with these limitations in Features. By default, we exclude from packaging configuration that was provided by enabled extensions. We make an exception for the install profile that was used to install the site, on the assumption that a feature developer may wish to repackage configuration and offer a custom install profile. (This is why you're ending up with configuration from the 'standard' install profile in your features.) We also make an exception when packaging into a new install profile, in which case we allow packaging of configuration that was provided by other extensions. All of this is configurable in Features, by editing the configuration of particular package assignment plugins.

Besides overriding in a custom install profile, another possible strategy would be to alter configuration, merging in changes--see #2614480: META: Enable capture and export of configuration overrides. Core includes a configuration override system, and there's a Config Override module for Drupal 8. Another initiative is Configuration Merge (no code yet).

The fix to this issue is planned to be implemented on another set of modules.