Any recommendations to 'generically' (or 'generally', not referring to 'generics') have ThreadLocal variables follow the execution of a co routine that is dispatched to a different thread. I know I can do it with a custom dispatcher (I think -- haven tried yet) -- but this seems like a common design pattern.. Example in this case is log4j thread context stack and maps (CDC,MDC) -- the desired end-state is a way to bind the call stack affinity of functions - co-routines or not - with the common java convention of using ThreadLocal to do that. Of course while NOT breaking other reasons for using ThreadLocal which have no relation to call stack. Something like a XSLT with-param. The 'new' coroutine scopes are similar but they have been very 'brittle' for me as they require (in ways non-obvious to me) that the scope is lexical -- so if you call a function it loses track of the current scope. I understand some of the rationale for this -- but its actual use can be very subtle and cause difficult to debug errors. similarity is thread context variables, especially from 'third party' Java libraries - which reasonably assume that threads will not change if you are in the same call stack ( and don't hand a lambda off to a thread ... ) It seems that there is or could be some kind of library or convention to express this easily. These two language features/problems are similar in several ways -- analogous solutions in the java world include variants on conventions how class loaders are searched -- although those are fraught with inconstant or non-obvious convention differences as well -- including kotlin scripting where its more then non-obvious WTF class loader a compiled or invoked script will inherit. A general concept of how one manages non-local Affinity consistently would be very useful. Many frameworks resort to the classic 'pass a context variable to every function' to solve this. I have yet to find anything 'better' -- but even that convention fails unless you are in control of 100% of the source -- and happy to add yet another argument to every function in your app.

That seems pretty much exactly what I was looking for !!! Thanks !