I understand what you are saying but in this particular instance the developers are working in isolation on seperate objects within seperate schemas and due to the nature of how database projects work in VS it does not lend itself to parrallel development on seperate branches.
Take my example above:
DevA adds a single file to the project in the location schema1\Tables\t_fancyfeature1.sql
DevB adds a single file to the project in the location schema37\Tables\t_fancyfeature37.sql
Neither is working within the same schema or indeed the same files however each time a file is added to a Visual Studio Database Project an entry for each new file is added to the .sqlproj file automatically as a result of the developers actions of adding an object rather than something that perform themself.
In the case of DevA the .sqlproj file has been modified by visual studio itself adding these 3 lines, lets say at lines 30,31 and 32 in the file
<Build Include="schema1\Tables\t_fancyfeature1.sql" />
In the case of DevB the same file has been modified but as it is not aware of the additions from the other branch which has not yet been merged to master it also adds 3 lines at the same line numbers
<Build Include="schema37\Tables\t_fancyfeature37.sql" />
Whilst your points are entirely valid if various developers were actively modifying the same files I would agree its a co-ordination and communication issue but in this case, in my opinion it is an issue with how database projects in visual studio do not lend themselves to concurrent development utilising a feature branch method.
MCITP SQL 2005, MCSA SQL 2012