Perhaps this is documented somewhere but I could not find it and there are some in consistencies that need addressing.

I have read this issue http://drupal.org/node/1279642 which is saying that this issue is not a bug. I would like some clarification on why it is set up to work this way and perhaps give some compelling arguments to why it might be better to be different.

If I create a feature of a content-types:node I get the content-type and all the fields attached to it. This makes sense. A content-type is really a holder for fields.

If I add a new field to that content type I see no change in my feature - it is not overridden - and there is no diff. I can recreate the feature and add the specific field.

With Drush things are slightly different.

If I do a drush features-list it does not say that it is overridden.
If I do a drush features-diff I see my added field and get this message - Overrides: drush features-update will update the exported feature with the displayed overrides

If I do a drush features-update I get my new code including my new field.

IMO if I do a drush features-update and get new code that means there is an override and it should be displayed in the list and in the UI interface.

I am sure that some smart people had good logical reasoning to do things like this but I don't understand the reasoning.

With drush able to show me the diff and do the update I can survive fine but I believe this inconsistency between the drush way and the UI way should be addressed.

This seems to be similar to adding a new page to a view and not having it show up as an override. (it does show up as an override) Again IMO pages (or blocks) are to views as fields are to content-types. Can anyone fill me in to the logic?