I have always been wondering why Windows Installer only allows you to install one program at a time. It is very frustrating not to be able to launch multiple installations, especially when setting up a new installation of Windows. What is the reason for that?
It would be very complex to guarantee correctness, when concurrent installations take place - assuming that they share some of the files. This would need some form of transactions.
These concepts are known from transactional databases - but the topic isn't trivial, and you usually don't find a fully transactional infrastructure in file systems (even though journaling file systems provide a part of that). One problem is, that multiple locks can lead to a deadlock - then you need deadlock detection (or both installers will hang forever), and a way to treat that. Deadlocks can be avoided (e.g. by always locking files in the same order), but there are other problems:
If you lock all the required files up front, you get effectively what you have: One installer must wait until the other is finished. If you don't lock all required files up front, and keep on going, you risk that the "transaction" will fail. That would mean, that one of the installers would have to be restarted.
Then you may have to think about transaction isolation levels - to be fully correct, your transactions would have to be "serializable" - but that's not easy, even for many databases.
There may even be alternative strategies to deal with the problems, which circumvent full isolation, but it would usually be even harder to prove their correctness.
I believe, with concurrent installation, we would have a lot more intractable post-installation problems - especially because I don't think, an OS vendor (or a distribution) would go through all the trouble to make it 100% clean. So I would prefer not to use it, even if it were offered by the OS.
But maybe what you really want is not even installing "at the same time". Maybe it would be sufficient, if you could queue up the installations, which are then executed one after the other (ideally without asking any questions in between). And that's really something, some other OS (distributions) handle a lot better.
On Linux, there is a database of all installed programs and that database is single-threaded, so only a single process at a time can access it. This is similar to the "Installed Software" view in the system controls but I doubt that Windows is using a database here because locating the installed software takes so long.
So the only reason I can think of is that installation is such a brittle process that people who write those installers just forbid it because it might cause problems.
Just for comparison: I've upgraded my SuSE Linux system from 6.3 upto 7.3 every time (that's five major upgrades and thousands of smaller ones) over 3 years without once reinstalling the system. I added and removed programs, etc. In the end, I did a complete reinstall to get some new features which were not activated because of my old config files but the system was stable as a rock.
Imagine upgrading from Windows XP to Vista to 7 without reinstalling.
This is by design, in order to avoid having two installations manipulating the same files/folders/registry keys/etc.; it could probably have been done in different ways, but Microsoft made this choice.
You can kick of several MSI files to install in rapid sequence one after the other using a batch file. You can not run two MSI files simultaneously in the sense that they both write to disk at the same time.
The reason is that part of an MSI installation is run as a "transaction" - a sequence of changes that are either committed or rolled back depending on whether the actions in the transaction list complete without error. All must complete without error, and then the transaction is committed, otherwise a full rollback of all changes occur. It follows that only one such transaction can be active at any given time.
At the technical MSI level, only the actions between the standard actions InstallInitialize and InstallFinalize in the InstallExecuteSequence are run as a transaction. No system changes are supposed to happen outside these actions, but sometimes MSI files are erronously designed to make changes in other sequences.