We successful implemented a hack to circumvent this limitation, in a pure AIR way, without having to change the publisher id (which needs multiple certificates, I think).
As you know, AIR is implementing its Mutex by using a unique application identifier. This identifier is calculated using the application id, and the publisher identifier (extracted from the certificate that signed the application).
In the installation directory of an AIR application, there is a META-INF folder (or in /share/ using Linux). This META-INF folder contains an AIR folder, which contains an "application.xml" file. This file contains a <id /> tag that defines the application identifier, which is used in the calculation of the mutex identifier. If your application can write in the installation folder, you can use the File API to edit it at runtime, randomly changing the <id /> tag, allowing multiple processes of the same application to be run at the same time.
This is having some annoying side effects, like creating a new folder in the File.applicationStorageDirectory folder every time. But using a LocalConnection, you can minimize this by reusing the same identifier multiple times by logging which ones are free to be reused. Also, SharedObject are stored in this folder, so cannot be used (or have to be copied every time a new instance is created, and synchronized though LocalConnection).
As far as I know, Adobe isn't planning to remove this native limitation. It was implemented for multi-platforming purposes, specifically on MacOS, where the dock is making that more complicated (it's not very easy to start the same application twice with the dock).
The official way to do that is to catch the InvokeEvent.INVOKE event, and do stuff like opening a new window. And there's no change planned for AIR 2.0 in this behaviour.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
