There needs to be central coordination in order to ensure a convergent process, and that, in my experience, is exactly the role of the orchestrator. It may be,
that this is what slide 2 is expressing â but that is not clear to me.
From your comments I think we are actually completely aligned! But because this new way of thinking about an orchestrator is so different, I simply prefer to call it a "coordinator" rather than an "orchestrator". The more classical type of orchestration (provisioning, installing, configuring, deploying, etc.) is still there, but it happens locally in the halo platforms. And that's where I think some of the problems you mention (convergence, event storms, event loops) are tamed. Out there it's really traditional orchestration in many respects, but handled very locally and very specifically (non-generically), so it's much easier to define, test, and debug. As for it not scaling -- well, the pyramid model is already failing us in terms of scale. Scaling our networks is an ongoing challenge and the only way forward is innovation.
Also, I was just showing an example in which the "coordinator" is broken up into several components. My intent was not to make them hardcoded. It does not have to be per my example as those roles could definitely all be centralized in one "coordinator" product or otherwise organized and distributed. The point is that there are various components that have to live in the center (rather than "the top", as in the pyramid), which is where they can get a global perspective and make global decisions (declaratively).
But yes, I agree with your bottom line that this scheme cannot work without regimented collaboration. It's definitely not just a happy circle -- there has to be some shared source of truth, and policies will become more and more important as we move towards this scheme -- policies that can adapt, clash, reconcile, and allow for necessary exceptions. If you insist on calling this "orchestration" you are welcome to, but it does represent a very different paradigm from the classical pyramid. And really that's what I'm trying to do here, to ensure that TOSCA 2.0 supports multiple orchestration paradigms, including cloud native ones that are still a work in progress.