I'll reply just once more, because it seems there are communication issues that I am apparently failing to address.
Ultimately, the application of game rules in wargames, rpgs etc. is a sequence of transformations of the state space of the game, each meant to model how an elementary event transforms the game world: you apply them one after the other, with the implicit understanding that you apply them in the same "order" as they happen in the game world, and one transformation must be completely applied before the next starts being applied.
There are times, however, when the "order" in which events, for which you have individual resolution mechanics, happen in the game world is not clear or does not exist - e.g. if events X and Y are simultaneous. In these cases, a mechanically rigorous set of rules will explicitly tell you what to do. The simplest, safest, cleanest solution is to tell you some way to serialize the events, i.e. to tell you that the outcome will be the same as if the transformation modelling X happened first, and that modelling Y happened next, or viceversa. It's very clean, because you do not need to introduce a new mechanic to handle simultaneity, except perhaps to decide the serialization order where it matters - many initiative systems ultimately do this. In this sense, note that when one opponent attacks another, and the other then attacks the first in the same combat round, the two actions do not really happen in completely disjoint time intervals: the "second" attacker is probably starting to swing his mace before the "first" attacker has fully completed his rapier lunge.
A more complicated approach is to define for X-and-Y-together a new transformation, different from that of first-X-then-Y and also from first Y-then-X. This is sometimes more satisfying, as it allows for a richer set of outcomes (such as two opponents simultaneously slaying each other, which in many combat mechanics is not possible). So you often find it in rules-heavy (sub)games, such as Exalted Combat. The crux, however, is that any rigorous mechanical system will tell you how to handle simultaneous events, either with an ad-hoc rule, or by serializing the mechanical resolution.
And unfortunately, Ars Magica does not try to be a rigorous mechanical system - in fact, it actively eschews such rigour in favour of a more "whatever feels right" attitude. And with multi-casting it tells you that stuff happens simultaneously, but gives you explicit (and still a bit fuzzy) X-and-Y-together rules to handle such simultaneity only on the caster's side. In this context, what happens on the target's side is mechanically undefined, because the only resolution mechanics we are given are for non-simultaneous events. This means that any mechanical resolution of such simultaneity on the target side is left to the troupe: there is no canonical answer in the RAW. I hope this is abundantly clear.
In this situation then, in my opinion, the safest and simplest solution is the same as always: serialize in the absence of explicit simultaneity mechanics ("first roll A and B and in the order decided by Player 1, then adjust C, then ..."). Which does not mean to assume that the events are not simultaneous in the game world. It just means to assume that the mechanical outcome is the same as if they happened one after the other. Sure, the result might appear a little in contrast with how one envisions what's happening: as I said, engulfing a target in five simultaneous, identical, co-located bonfires should not really cause any more damage than engulfing him in one. But at least resolution is generally clear and simple, and in most cases, not that much coarser an approximation than what you'd get with some ad-hoc rules.