Is that your axiom or do you have any justification? I just don't agree with it.

Why should the server know about a datepicker's internal details?

There's some case where local state is more important (figma, google maps, chat app) and the backend is expected to act as a data source with a domain-specific API. Any mixture between the two and you will make the separation between the two domain (server concerns and client concerns) at the wrong place, making the design more complex (however well you hide it behind the curtains).

Which is exactly why the client state should be transient non-application state like datepickers, dropdowns, text boxes, etc. and it does not belong in the server (essentially what jQuery was used for back in the day, interactive sprinkles). And the other way around.

Perhaps you agree with me but there was something lost in translation?

RSC does a weird split where the engine is the same on both ends instead of a clear separation layer where one does not need to know about each other. I much prefer HTMX approach (samey old backend where you mostly take care of everything in the frontend) and Laravel Livewire approach (where you take care of everything backend side, with optional client side scripting).

No need to reinvent the world to fix a single problem.

I posit that any composable version of sprinkles or the “island architecture” will closely resemble RSC.

Only a small fraction of apps will ever use the full power of the RSC architecture. However, the React team doesn’t build apps, they build primitives for building apps. And good primitives are composable.

What they did wrong tho was to morph React into this mess. RSC should be React Server and live along React DOM and React Native, something almost unrelated to the previous concept of React. But we got this an entangled mess.