I started investigating that. I might have good news: asynchronous publishing might be fine. But the bad news is that I can reproduce it without it... see this gist: https://gist.github.com/bdunogier/b47784a14a9cc946a0c6.
(run with ezexec.php)
It creates one content and 10 versions, and publishes them all in //. Play with the commented code to publish using asynchronous publishing or... just ask me. Anyway, I get 10 publish versions with or without async pub.
It sounds quite clear to me that this is a pure locking issue. Note: we have a clear UX thing here... some people want to edit multiple languages simultaneously. Maybe this is where we should offer a workaround in some way...
Anyway, the issue should be quite clear:
1. all processes start at the same time
2. when they start their transaction, there are 10 drafts in the database, one being published
3. archiving does nothing, since there is nothing to archive
4. the published draft is marked as published
1. Locking would work.
2. Asynchronous publishing could ease that out by only sending 1 version of the same content at the same time. I've actually been thinking about that. Can suplement #1 by hiding the dust for the user.
3. Think of another trick. A workflow where you can edit in a language, store the draft (v4), edit a new language on top of v4, store it (v5), and repeat ad nauseam until you hit "Send for publishing".
Overall, it really feels like a misuse of a product where the use-case is not covered.
I'd also be very surprised if there wasn't severe consistency issues in data... if they're not published in the right order, copyTranslations in the publishing transaction will miss translations that are being copied.
*Overall: I don't think we can really support publishing of multiple versions at the same time. The database part needs to be sequential, at the very least*