I'm looking at this from a holistic language design angle: since one of our go-to solutions for concurrency problems is the actor model; We're lacking expressive power for some situations, like reentrancy which is one of the issues people frequently hit today. So I was asking if your examples aren't actually all about that specific problem, for which I believe we should figure out a solution without having people "drop down to manual lock/semaphore management style".
Another potential area to explore I can think of is shared isolation domains between some actors (achieved dynamically by sharing a custom serial executor by a few actors).
Rather than give up the entire actor model and go back to locks and semaphores, and especially litter actor code with locks and semaphores (even if async ones), I am interested in exploring ideas how to make it possible and simple to understand for people to use actors for these use-cases. The more ad-hoc lock/semaphore solutions we're allowing.
I'm not against introducing more low level concurrency control, in fact I'd welcome it -- like the synchronous locks being pitched now, I'm quite excited for this actually. But I do think that as we expand synchronization capabilities of the "low level" kind, we should not miss the chance to keep improving the "high level" kind (actors, tasks, groups). In this thread we jumped to the latter very quickly, which had me concerned.
I think you did confirm though that the issues you are trying to address are mostly reentrancy issues right? What if we allowed reentrancy control on actor methods instead?