True Rename, not those delete/add solutions, is one of those things that is extremely tricky to get right and even more on merge scenarios. Unfortunately, I have seen some of our customers struggle with them resulting in confusion within the organization and at times build breaks. For this reason, I wanted to write a quick blog post to outline one of those things about our product that "does not make sense" but it happens, which can get you in an inconsistent state and hence mad at us.
We will be working to find out how to solve this issue, but in the mean time please have as a good practice to always merge at the root.
The file inside FEATURE1 is still called foo.cs
Well, now you ask why if the range includes the rename this is not bringing it over. What happens if something else is dependant on this new name?
Now there are reasons but at a high level I think we need to rethink our reasoning and see if we can handle this scenario better.
The solution is simple, merge at the root. If you execute a merge between MAIN and FEATURE1 everything will work as you expect, and you get a conflict because for us all renames are conflicts. Go and select Merge Changes for Me and select the name you would like (bar.cs) and you have completed the merge.
Regardless of our logic we will always recommend our customers to merge renames and for that fact a lot of the changes at the root instead of executing it from an individual file, so please keep that as good practice.
Hopefully this saved you some headaches and if you see other things like this one let us know.