The high level question here is reasonable -- e.g. in Akka and Scala this is done by a "parasitic execution context" (it sounds nasty to prevent people from using it... long story). So... Can we just make this an executor? Scala provides no compile time safety or trying to bind isolation guarantees to what parameter was passed somewhere.
It would have to be a specific serial executor, and the isolation of the closure would have to be the same as the passed executor... So... this is kindof asking for the future direction that we say is too complex to implement currently:
isolation: isolated (any Actor)? = #isolation,
operation: @escaping @isolated(to: isolation) sending async throws(Failure) -> Success,
Regarding the Job idea -- I don't see this changing anything here...? a) Job is not user API, so that's off the table for that reason to begin with. b) You can write an executor which just runs the first job inline, in fact, we'll basically have to write such thing to service this job.
If we were to pursue this idea we'd need... have this work only with passing a specific actor, like (some ancient discussions may have seen that mentioned somewhere): Task(startingOn: actor) but that:
- a) boils down to the same operations really (and the @isolated(to:) need, which we can't do right now)
- b) goes against the language direction of "specify the isolation of the closure" that closure isolation control is all about Closure isolation control
So we've been trying to lean into this "closure isolation control" proposal, and the fact that we are not able to express the API we'd actually want: @isolated(to: someParameter).
If you have a more specific writeup that could be useful, because I don't think I was able to fish out something actionable so far 
I could have missed your point perhaps as well, examples would be great - thank you!
edit: I wonder if the startingOn could make a comeback... maybe it would then be addTask(startingOn: #isolation) but we hit the @isolated(to:) problem sadly then... 