One more vote from the community: We use "copy with history" heavily in the other version control systems we use (or have used). Once you have used this feature, you will not want to give it up. It promotes intelligent reuse and attribution within the project community.
And now...this is the big deal for us...you need a command like 'bzr showforks <file>' to do the following:
For a given file, file all instances (ancestors and descendants, regardless of name in the filesystem) of forks. This is important! Although it would be dangerous (as others have noted) to automatically propagate changes (in which case you should really have a link to a single file anyway) being able to transparently expose all "fork relations" for a file is essential for maintainability. This allows an intelligent decision (or code review) to determine which changes should be cherry-pick-merged back/across and *where* they should be merged.
I would not be concerned about implementation efficiency in the "showforks" command. It's used rarely. Only two places need the fork marker: the parent and the child. This is sufficient to ensure that following the line(s) of descent and the line of ancestry will find all forks, even if it takes a while.
I suppose this might be pretty disruptive, but perhaps it could be worked in parallel with other requests for metadata, for example https://bugs.launchpad.net/bzr/+bug/218128 .
It would be great if this could