Respuestas:
Sería muy complejo garantizar la corrección, cuando se realizan instalaciones concurrentes, suponiendo que compartan algunos de los archivos. Esto necesitaría alguna forma de transacciones.
Estos conceptos se conocen de las bases de datos transaccionales, pero el tema no es trivial y, por lo general, no se encuentra una infraestructura completamente transaccional en los sistemas de archivos (a pesar de que los sistemas de archivos de registro en diario proporcionan una parte de eso). Un problema es que los bloqueos múltiples pueden conducir a un punto muerto; entonces necesita la detección de punto muerto (o ambos instaladores se bloquearán para siempre) y una forma de tratarlo. Se pueden evitar los puntos muertos (por ejemplo, siempre bloqueando los archivos en el mismo orden), pero hay otros problemas:
Si bloquea todos los archivos necesarios por adelantado, obtendrá efectivamente lo que tiene: un instalador debe esperar hasta que el otro haya terminado. Si no bloquea todos los archivos necesarios por adelantado y continúa, corre el riesgo de que la "transacción" falle. Eso significaría que uno de los instaladores tendría que reiniciarse.
Entonces puede que tenga que pensar en los niveles de aislamiento de las transacciones: para ser completamente correctos, sus transacciones tendrían que ser "serializables" , pero eso no es fácil, incluso para muchas bases de datos.
Incluso puede haber estrategias alternativas para lidiar con los problemas, que evitan el aislamiento total, pero generalmente sería aún más difícil demostrar su corrección.
Creo que, con la instalación simultánea, tendríamos muchos más problemas difíciles de resolver después de la instalación, especialmente porque no creo que un proveedor de sistemas operativos (o una distribución) pasara por todos los problemas para hacerlo 100% limpio. Por lo tanto, preferiría no usarlo, incluso si fuera ofrecido por el sistema operativo.
Nota
Pero tal vez lo que realmente quieres es ni siquiera instalar "al mismo tiempo". Tal vez sería suficiente si pudieras poner en cola las instalaciones, que luego se ejecutan una tras otra (idealmente sin hacer preguntas en el medio). Y eso es realmente algo, algunos otros sistemas operativos (distribuciones) se manejan mucho mejor.
Esto es por diseño, para evitar tener dos instalaciones manipulando los mismos archivos / carpetas / claves de registro / etc .; probablemente podría haberse hecho de diferentes maneras, pero Microsoft tomó esta decisión.
Puede patear varios archivos MSI para instalarlos en una secuencia rápida uno tras otro utilizando un archivo por lotes. No puede ejecutar dos archivos MSI simultáneamente en el sentido de que ambos escriben en el disco al mismo tiempo.
La razón es que parte de una instalación de MSI se ejecuta como una "transacción", una secuencia de cambios que se confirman o se deshacen dependiendo de si las acciones en la lista de transacciones se completan sin error. Todos deben completarse sin error y luego se confirma la transacción; de lo contrario, se produce una reversión completa de todos los cambios. De ello se deduce que solo una de esas transacciones puede estar activa en un momento dado.
En el nivel técnico de MSI, solo las acciones entre las acciones estándar InstallInitialize e InstallFinalize en InstallExecuteSequence se ejecutan como una transacción. No se supone que ocurran cambios en el sistema fuera de estas acciones, pero a veces los archivos MSI están diseñados erróneamente para realizar cambios en otras secuencias.