It sounds like your primary use case is selecting which work items from one stream should be applied to another stream. 

The simplest approach is to make the initial change to a stream that "flows into" the other stream.  For example, commonly, all the changes from a maintenance stream will flow into the current development stream.  So if you have a change that needs to be made to both maintenance and development, perform the change in the maintenance stream, and then that change will automatically flow into the development stream.  So in particular, review where a change should go *before* you start making the change in the development stream

But suppose that you are concerned that people are not being careful about making changes in the right stream first, and changes that should have been made initially in the maintenance stream are mistakenly being initially made in the development stream.  The approach I usually use for this case is to create a "review-for-backporting" stream, where the stream containing changes to be reviewed (such as the development stream in the above example) is marked as flowing into this review stream.  Then I periodically, use the pending changes view to determine whether there are any new changes in the development stream.  If Ifind a change that needs to be backported, I add an Approval to the appropriate work item, indicating it needs to be backported.   If during the backport operation I discover I need to actually create a patch or do some merging, I'll create a backport work item, to hold that work.

Searching for work items planned for the iteration that you want won't guarantee that the associated change sets have been delivered for that iteration. It's possible to have a work item with change sets that never get delivered to any stream or even to the wrong stream. The work item only shows intent on where the work will be delivered.

You can search for change sets using the Locate Change Sets editor. If you right-click on a change set, you can check if it exists in a stream. If you are on a version before 4.0, the locate change sets option is still there but isn't as fully featured compared to 4.0.

Based on what you want to do, it might be better to have a related task to the defect for delivering to the maintenance stream, or dev stream if you prefer. This would track the task of delivering the change set and any other work if the change set doesn't apply cleanly to the other stream.