Isn't the wider problem that people don't try to understand the internals? Some of us may read the code of modules we "require", but experience tells me this is a rarity.

For those that do, this isn't an issue, and for those that don't, this isn't an issue either. Their mental model may be flawed, but as long as the IO is the same, do they really care?

Concurrent mode isn't really a black box. Its just a shortcut to throw away work that would otherwise be invalidated.

I noticed at the end of the blog post you stated that you're very excited about the debut of the upcoming Concurrent Mode (CM) in React. I've read about the problem that Concurrent Mode is working to address; but I'm confused as to why React needs this additional feature set when I'm unaware of any other UI frameworks which have a feature set that seem to mirror that of CM. Vue or Svelte do not seem to need these additional features to achieve comparative rendering benchmark speeds to React, and I'm unaware of any holes in these frameworks that something like CM would adequately address. (?).

Is Concurrent Mode basically a way of addressing performance problems in React, or is this in some way a feature that adds something novel? Or is it just a side effect of an unwillingness to move away from functional programming?

I write React at work, but write Svelte or Vue at home, and I've always found React's abstractions to be the most hard to reason about, and from the looks of it CM will make this more challenging (??). Thanks.

I usually explicitly tell devs to not worry about React internals. Let React decide when to re-render or how to batch state updates. React's API is small, developer time is better spent understanding the API than wondering how React works under the hood.

That said it's still a mental shift. Sometimes I feel like I'm writing React and not writing JavaScript.