MSI "knows" what is installed via a number of GUIDs embedded in the installer. This design is "inherent" to MSI and is hence "by-design" not intended or adapted to multiple instances outright:
Package Code: Uniquely identifies an MSI file. This GUID should never be the same between two MSI files unless it is the same file that has been duplicated (then it is the same file of course - binary identical). If two MSI files are different and have the same package GUID they are treated by-design as the same file. This can cause some of the most mysterious problems you ever have faced. Always auto-generate this GUID (it should never have been exposed technically?).
Product Code: Identifies a unique product instance of an installed product. You can not install the same MSI over and over again with identical product GUID. You can in-place upgrade the existing installation using a minor upgrade (then product codes are identical between MSIs). This yields a single updated instance and not two side-by-side installations as you like. This is the GUID that makes your second run of that MSI show up in maintenance mode (repair, modify, uninstall) - as in "this product is already installed". There are some complications here with package code being involved though - technicalities (you can't easily fool it - don't fight MSI it fights back).
Upgrade Code: Identifies a family of products. Products that are related somehow. Usually used to implement major upgrades. In other words to replace older versions already installed with a new and higher version. Should generally be stable across related releases. There are other approaches. Know what you are doing.
There are ways to deal with this. Here are some suggestions:
So essentially: 1)
Virtualize, 2)
Side-by-side install, 3)
Instance Transforms. Or 4)
just use a legacy non-MSI installer?
For a simple product with no registry entanglements you can simply duplicate the folder, but for a real product that is rarely the case. There are COM servers registered, GAC-involvement, file associations that conflict and numerous other problems that often lead to virtualization being the "least worst" choice.
Side-by-side installation requires a number of technical tweaks as well - most significantly changing all component GUIDs to be valid MSI - unless you use the instance transform concept (which I don't use).
WiX has introduced the concept of "auto-guids". These are component GUIDs that are automatically generated (for most component types) so that they can change depending on where you install on disk. Blog from Bob Arnson: Simplifying WiX component authoring.
There are also features to simplify WiX source xml.
Links: