For Context support, https://github.com/vercel/next.js/discussions/42301 isn't promising, and https://twitter.com/sebmarkbage/status/1587615484870098945 explicitly suggests you might need prop drilling.

I'm really sad that tree-specific context for server components seems to be an afterthought. As the Twitter thread suggests, if you have something that can be used across all the server components for an entire request, you can use the cache functionality or rely on Next's URL parameters. But if you've relied on Context as a way to let deeply nested components access some kind of business logic that's specific to only a part of a rendered page, and if you want/need those components to be server components, you'll need to switch to explicitly drilling the props through.

For Context support, I think the reason it's not supported is because Server and Client components have different lifetime. In theory they could add something like Server Context, that's accessible only to Server components.

For CSS-in-JS, those are all 3rd party libraries, so they need to adapt on their side. For example, `styled-components` uses Context heavily, so they need to re-think their approach. For `css-modules` adapting to Server components looks doable, but requires substantial amount of work.

A better name for context is Client Context. On the server can you not just use a pojo?

For CSS-in-JS/TypeScript, PandaCSS and Vanilla Extract are both good options.