A clear mental model on how feature components should act on uninstall/disable

Symptoms of the problem

Looking into issues like these,
http://drupal.org/project/issues/features?text=disable&status=All&priori...

It appears there are quite different expecations for what happens if you disable/uninstall a feature.
Let's say, the feature defines a node type. Now you uninstall it. Does the node type disappear? Are nodes of this type being deleted?

And what if you modify the code of a feature?
The info file, or anything else..
Will this have an immediate effect?

And,
is there a way for #663136: Provide way to Import views/true exportables back to the database

The real problem

I think what we really lack is a good mental model to explain what Features does, and how it works.
In the documentation, I see too much of "nothing easier than that", while essential questions like the above remain unanswered.

A proposed mental model

So, here is how I would put it.
I might be wrong on some of these things, so feel free to correct me.

Aspects of a feature module:

1. The configuration on the site itself, sitting in the database.
2. The code of the feature module, sitting somewhere in sites/all/modules/(custom/)features
   1. The part of the feature module code that defines which elements/aspects of the site to track or control. Let's call this "definition code". I suppose that's in the info file?
   2. The part of the feature module code that actually stores the information about the tracked elements/aspects of the site. Let's call this "configuration code". I suppose that's anything outside of the info file?
      Some of this code defines what should be in the db (such as, content type definitions). Other code replaces what would otherwise be in the db (such as, views).
3. Whatever the database stores about the feature module. Is it enabled or not? Any cached version of whatever is in the feature code? (I would like to know more about this)
4. Whatever you download when you repackage or create a feature. I put this separately, because newly created features do (afaik) not go directly to sites/all/modules/features, but you have to download them first.
5. Finally, what does the visitor get to see? E.g. a view ("views" module) can be defined either in code (the feature module), or in the db (independent, or overridden feature module). For the visitor, these two are equivalent.

Operations on a feature module:

drush en [feature name]

Some of the functionality in the feature module installs itself into the database via hook_install(), and stays there (such as, content types). Other functionality (such as, views) is provided from code directly, without writing itself to the database.

drush dis [feature name]

Functionality that installed itself into the database might now become uninstalled. Functionality that lives in code alone and was not overridden, simply ceases to exist.

drush features-update [feature name]

Site conf (database, 1) -> write to feature's configuration code (2.2), based on its definition code.

drush features-export

?

drush features-revert

?

manually add to the *.info file, while the feature is enabled.

yeah, what will this accomplish?

manually remove from the *.info file, while the feature is enabled.

I suppose, this will "unlink" the site configuration aspect from the feature?

manually change the php code in any of the other files

I guess, this does nothing, until I revert?

All these operations could be illustrated with arrows between the different aspects of the feature module.

Combined operations

Someone who understands these operations, can also predict what combinations of them are supposed to accomplish:

Example:
Enable/install a feature.
Remove everything from the *.info file.
Disable/uninstall.

I suppose this way we can create a node type from a feature, then let the site forget that this node type belongs to the feature module, and finally remove the feature module "silently", without it removing the node type or any fields on it.

Am I correct on all this?
Let's iron this out, and turn it into some useful documentation.