If you performed the above steps, you'll notice that your new content type B changes has caused your Feature A feature to change into an overridden state. But why? Aren't they different? Sure you reused some fields, but doesn't CCK allow for the creation of Field Instances (or copies of already created fields)?
Yes, it does, but not for all settings on a field, in particular, cardinality. If you take a look in the database table field_config, you'll notice there are a handful of rows in it. One of the rows in the table is called "cardinality". This is the value that defines whether a field can be added X number times to an entity it is applied to. Its a setting that is controlled in the Base Field definition for the field.
Stop trying to figure out why your features that contain the base field definition constantly get overridden. Create a new field if the cardinality needs to be different from any other fields that do the same thing or perform the same functionality. Currently, its the only way to work around this if your running a heavily driven features site.
I would be awesome if we were able to create new copies or instances of fields and provide these settings as unique to the field instances, but currently this is not how it works. Mike Potter put together a nice writeup of some of the changes made to Features in regards to Field Bases and Field Instances inside of features and the reasons behind the changes: http://www.phase2technology.com/blog/new-field-bases-and-instances-in-features/