New answer by me, especially to the "equal version" problem.
Two approaches possible:
First approach: Testing! Compare the install result with the source, at least before you ship the setup. Always a good recommendation. Then beating the developers who forgot to increase their version numbers and saying "MSI is requesting you have a clean version handling. If not, your file is not overwritten over an existing older version." Have done this. Has worked. (Not necessary in first version, but in updates.)
Second approach: Use always the property REINSTALLMODE with "e". This means always override existing file with file version (file level rule only). E.g. you put in your MSI hardcoded the property "REINSTALLMODE" with value "emus". This still allows you to override it, e.g. for repair, where it should be "vemus". More clean is to set this property only in the commandline but then you need a setup.exe or other bootstrapper.
This second approach is more comfortable, but now you have losed a very clean file version handling. If you have a shared file in two different setups (products) of your company, with version 1.0, which is really older, it will be overwrite the "newer" one which has also V1.0.
If you have no shared files, it works. But you are relying now really on the version managagement of the setup update process, so it is even more important, to assure, that the product 1.1 (not the file) can not be installed over a newer product version 1.2 or 2.0 for example.
Third approach (added later):
If you only produce Major Upgrades in MSI, e.g. no patches, and you rely on the "uninstall old version before install new version" strategy (e.g. the default in InstallShield), then "normally" you will never have a situation of overinstalling files, given some conditions (like having no shared files, again). Don't use merge moduls of MS if doing this, except you are an expert.
There are not really better alternatives.