change flow target results in incoming becoming outcoming
One answer
Second, it is good to be explicit (both in your head, and in your post) about what the names and purposes of the workspaces and streams you are dealing with. So what are the names/purposes of your 3 streams, and what are the names/purposes of your 2 workspaces?
As to what "change flow target" does ... that specifies what shows up in the Pending Changes view, what stream/workspace your change sets will flow to when you hit "Deliver" or "Accept". So changing your flow target does not change which change sets are in any of your workspaces/streams ... it just determines where changes will be made when you subsequently hit "Deliver" or "Accept".
Note that a file is not "owned" by a work item or change set. A change set creates one or more new versions of a file, and a work item references one or more change sets (more than one work item can reference a given change set).
Comments
The project we're contributing was setup by others after porting from ClearCase/ClearQuest: Patches stream --> Integration stream <-- Development stream
Your stream setup is reasonable.
The reason you are running into trouble delivering is most likely that when your flow target is set to Dev, you are accepting all the incoming changes, which includes change sets that other developers have delivered to Dev, but which are not yet ready to deliver to Int. Then when you change your flow target to be Int, and try to deliver, it is telling you that you cannot deliver other developers changes (which is probably what your project lead thought she wanted, because only the owner of those change sets knows when those changes are ready to be delivered to Int). The problem is that this approach only works when every file is "owned" by a single developer, and only that developer makes changes to that file (and that clearly is not the case in your organization, since three people have made changes to a single file).
So you have some choices, each of which has some advantages and some disadvantages (i.e. there is no "right" way to handle this).
Probably the simplest choice is to remove the Dev stream, and instead do "personal builds" from your workspace. To keep things even simpler, each developer would have two workspaces ... a Patch workspace and an Int workspace (depending on which stream your change is intended for). Then when your personal build succeeds, you deliver to the current stream of that workspace. The downside of this approach is that while you are somewhat isolated from your other team-members ... you only see their work when it is ready to be delivered to Patch/Int, so you end up having to "merge" more.
To cut back on the amount of merging, you can bring back (keep) the Dev stream. But then you need to have your project lead turn off the "you can only deliver work items that you own" precondition. Instead, you would turn on a precondition that requires that a workitem be in a "completed" state before it can be delivered. You can still be temporarily blocked from delivering (if you have some changes that were made on top of other changes that are not yet complete), but eventually those work items you depend on will be marked as "completed" and you can then deliver your work.
There are other options as well, but these are probably the two most commonly used.