When adding a field to a content type, it is tempting to create a new field, and to assign it a name so unique that it could never possibly clash with the names of fields you may create in the future (at least in that particular Drupal installation). After all, most if not all Drupal developers have examined the field tables and columns in a Drupal database — in an attempt to determine everywhere that the field data is stored, and anything else in the database that can affect it — but have been frustrated when field names are similar enough to be confusing.
A simple example from my own experience can illustrate this situation: I created content types for articles and book reviews, and each type needed a publication date. So I unthinkingly defined two separate fields, "Date article written" and "Date review written". Everything was fine until later I wanted to create a view of the most recent published pieces, encompassing articles and book reviews. Using both date fields for sorting did not work, because it sorted all of the articles together in one group, and all of the book reviews together in a separate group.
The lesson learned was clear: If there is a chance that two or more fields of the same data types — but assigned to different content types — might in the future need to be mixed together in a view, then do not create new fields, but instead reuse a single one.