Ehhh, I’d argue the functionality it provides will be extremely close to what is described here. The biggest difference is that the “needs” functionality will be coordinated in a “parent” workflow. This actually provides a number of benefits, like showing clearer relationships between the workflows. The usecase described here is effectively an implementation of a reusable workflow (with limited number of reuses).
We now have composite actions that also deal with reuse, but does not solve the problem of having one expensive action run once before N number of dependent actions.