It depends...
How tightly (that is, to what level of detail) do you need/want to maintain the audit trail? Will you be using metrics? If so, to what level of detail?
For my money, it really boils down to one CR per concept. Again, it depends on the level of control/tracking desired. A lot also depends on the complexity of the product.
Here are some considerations or methods.
If the proposed change is simple and will probably result in a linear sequence of changes (req change, design change, product change, test change), then it maybe makes sense to include all those docs/files on a single change proposal.
In what I refer to as the chain method, each proposed change spawns a child change. That is, the requirement change proposal, spawns a design change proposal, which spawns a product change and a testing change, etc. A parent cannot be closed until its child is closed.
For my "key ring" method, the parent change proposal (against requirements) spawns a "bunch" of "child changes" to the other elements. Each child can be completed and closed, but the parent can only be closed after all the children are closed.
To keep you system "cleaner," you might want to consider NOT a specific configuration item but the nature or concept addressed by the change.
It also may depend on how much is known about implementing the change. To go back to the first method above, the linear sequence of changes, if it is known up front what all the changes will be (to the reqs, design, file, test), then it might not make more sense to use a single change document. So, knowledge about the downstream "impacts" is another consideration.
