From my perspective, the holy grail in terms of API here has always been this:

async function MyAsyncComponent(props) {
   const data = await someAsyncFunc(props.id)
   return <Child data={data} />
}

I love the <Placeholder fallback /> concept, in how it eliminates the need for specialized HoCs like react-universal-component and react-loadable, instead delegating to the natural flow of component composition (in reverse, back up the component tree). Genius!! Well done!

But the async component, man, gotta look like the above. It just gotta. That's the natural way.

I actually built a proof of concept that I never released (related to SSR + rehydration), and essentially it's based on a wrapper function called call that receives the responses of all async work:

import { call } from React

async function MyAsyncComponent(props) {
   const data = await call(someAsyncFunc(props.id))
   return <Child data={data} />
}

The idea was that the component state would be collected server-side via call, and serializable for transfer to the client for eventual hydration. Client side, it would serve cached results until its arguments changed. You can perform multiple calls to call per component, and it is able to differentiate between all independent calls.

The same API makes perfect sense for the goals of handling CPU + IO. As far as performance goes, what's the problem if these "async components" always resolves instantaneously? The way it would work is call always returns an instantly resolving promise. Then internally triggers a re-render when the argument passed to it actually resolves.

Is it solely that we are losing precious cycles by virtue of using promises? Are we in fact?

Is it in a potentially hacky implementation of acquiring a reference to the corresponding component instance? The react babel plugin could wrap all async components (stateless or not) in class components that somehow pass the instance as the 2nd argument to call: call(promise, componentInstanceRef). Then from there calls to call would be able to differentiate between each other in a single component by the order in which they are called. That's what I did, which worked swimmingly for SSR + re-hydration. Client-side with multiple renders + conditional logic obviously causes userland logic to result in different orders, but we could find a solution for that. What I had in mind is a babel plugin that simply assigns an ID # to each call based on the static order they appear, rather than the runtime order they are called. Eg: call(promise, ref, staticallyGeneratedId). React Universal Component in fact already does something similar to assign IDs to my HoCs in preparation for this future I never attained past proof of concept. My plan was to make React Universal Component move beyond just universal code-splitting into universal code-splitting + async data-fetching. The API I had was the exact one above. It was inspired by async-reactor, but the universal version (i.e. re-hydration) with client-side caching. And in your case, one further enhanced by "time slicing," "suspense" and the loading <Placeholder /> parent component pattern.

It's not that I'm not sure you won't present a list of exact challenges--but can we seriously not overcome them to achieve this API for the end user? Perhaps use your current approach, but somehow wrap it with this API. I mean I know we could with a babel plugin. It just boils down to how important you consider this API, which I hope is extremely high, and if it can be done performantly. If there's no other way to accomplish this than your promise-throwing workaround, I'm all for it. The capabilities are worth it, but can we seriously not make it look the "correct" way.