i was going to write something along these lines, but another thread on this same topic surfaced before i finished and @ktoso's reply there regarding how actor isolation inference works explains the difference in your examples here[1].
a small nit: as pointed out in the thread referenced above, in the original example the Tasks aren't isolated to MyActor since they do not capture the isolated self parameter, so they will in that particular case run concurrently with respect to each other. it's not that they are synchronous, but that the closure is inferred to be nonisolated.
apologies for the pedantry, but i think it is perhaps worth reiterating @robert.ryan's citation of SE-0304 from upthread that the ultimate scheduling and execution semantics for code like this is up to decisions made by an executor. for @MainActor code specifically, it explicitly specifies some details about the executor in the docs:
[The
MainActoris a] singleton actor whose executor is equivalent to the main dispatch queue.
but the precise behavior is still dependent on however the 'main dispatch queue' is implemented. it happens to be the case that the main dispatch queue is a certain serial dispatch queue, and so enqueuing and priority escalation work in a particular way in that context[2] (and this seems unlikely to change). but in general an actor could have a custom serial executor implementation, or end up using one from an inherited executor preference that had different semantics.
i guess i think the point to highlight here is that if you have specific execution ordering requirements, it's probably best to explicitly manage that rather than relying on behaviors that may not always work the way you want.