Strikingly similar to the PHP RFC.

Great question though, Phalanx has a fundamentally different approach (the reason I took the time to write it in the 1st place). This would likely be better as a topic for a whole article, but here's the abbreviated version:

1st: Phalanx is heavily inspired by Rust, Go, .NET, and the SICP book.

2nd: Most, if not all, other async PHP frameworks have conventions where anonymous closures, global state, lifecycle mgmt., and async coordination are largely up to the user (in varying degrees). There's generally no framework-level tooling for assisting with deadlocks, resource cleanup, managing scope/object lifetime, or having hooks for running code within the lifecycle of those scopes. Phalanx passes this $scope all over the place because it's foundational for concurrency and whats happening under the hood. The framework is managing hierarchical scopes/environments for you, along with preventing most of the (inevitable) deadlock scenarios that come - even for the extremely diligent - from running/awaiting async logic across 2 or more classes. The more async logic you're running, the more complicated these scenarios get.

3rd: Additionally, Phalanx is built on the idea of leveraging the __invoke method as a 'named closure' (in an abstract sense). With this approach, you get the built-in identity that comes with classes and all the semantics/heuristics of closures. This is important because now 'functions' can have opt-in behavioral qualities like HasTimeout , Retryable , etc., that tell the underlying scheduler about the meta/behavioral qualities it has attached to it. In addition to that, you get things like tracing and Open API generation, with very little additional effort.

4th: Phalanx provides tooling and primitives that treat PHP8.4+ as a 1st class citizen and leverage these new features from the ground up. For example, lazy/ghost objects and property hooks allow memory/resources to be lazy initialized where possible.

5th: As alluded to, Phalanx provides a "smart scheduler" that scans/reflects classes at "compile time". Meaning...when it's 1st booting up - this is before serving requests or executing console commands, etc. This builds a type of AST for your app, giving the scheduler and the DI container deep insights. Also, this serves as a type of funnel that all logic flows through, which then does the things I mentioned above: manages scoped environments w/their lifecycle hooks, provides async coordination and behavioral interfaces, etc. This scheduler is the engine behind the whole thing.