But what if this issue also applied to a different release being handled in a different stream -- in this case, the hierarchy under stream_2_1. In that stream, the fix needs to be made in a different set of files:
You perform the changes to these files in workspace stream_2_3_WS_2. Even worse, somebody else continues to work on issue #2 in the original stream and adds a new file named file_004.c which doesn’t even exist in Stream 2. Both developers promote their changes against the same issue, one from workspace stream_1_3_WS_1 and the other from stream_2_3_WS_2.
Now the change package is incomplete in both streams: the modified versions of file_002.c and file_003.c are not available under Stream 1, nor does the new file_004.c exist under Stream 2. If you do a Show Active Issues in both of the parent streams, you see two different incomplete change packages, each missing different files.

Make it a policy to not use the same issue to address problems in multiple streams. If you need to fix the same issue in another stream, create a new issue for that stream and promote files against that issue.