The sequential multi-instance behavior actually "wraps" the existing behavior (in your case, a subprocess) and executes it UNTILL the completionCondition evaluates to true or loop-count reaches it's end. At the time multi-instance was created, there were no async-continuations yet, making the synchronous looping approach valid.
Looks like, when async was added, there was no "special" handling introduced for multi-instance activities. The engine just sees it as ONE activity it needs to execute, with itself creates the parallel-executions which in turn are executed by the same thread. There is no quick fix for that I'm afraid…