Is the multilanguage support still a story for Pulumi? It's looking easier and easier to just build an ecosystem around the typescript side. How are python, go and others ever going to keep up with that?

Multi-language is definitely still our plan. There's two parts to that - raw support for each language, and then ecosystem on top of that. On the raw support side, we expect to keep extending support for existing languages and adding new ones in the coming weeks/months. (and it's been great to see contributions from @aloof-tailor-93191 recently on Go support pushing things along even more quickly there!) The ecosystem part is, as you note, a little less clear. Whichever language gets used most initially (TS/JS in our case), will get a head start on ecosystem that will then attract more users to that going forward - normal network effects. We hope and expect that ecosystems will grow around other languages as well, but these network effects will still play a role in user choice. The big win will be if we can find ways to leverage Pulumi components across language ecosystems - use a component authored in TypeScript from a Go Pulumi app. We have several ideas on how to enable this which we are exploring now. If one of these works out well, it would allow all those network effects to benefit users in any language. For the nearterm though, we are continuing to focus on both moving forward core support for a variety of languages, as well as continuing to build up additional libraries on top in individual languages. Both of these are useful in the near term but also steps we can build on with a longer term cross language component story.

That's reassuring that there's still a plan. I might have a first pass of dotnet runtime and terraform support in a week (toddlers permitting). Start making a push on the dotnet ecosystem :)

does it make any sense to try and make tfgen non tf specific and then get kubernetes to gen from that as well?

It might. Both tfgen and the kubernetes codegen are schema-driven code generation down to Pulumi type definitions. In principle, we could define a layer between each of these and the target languages - a Pulumi IDL - and then have tfgen and Kubernetes generate that, and define a single code generator for that into TS/Python/Go/etc. There's a bunch of questions about that, and they are partly related to the other topics around multi-language above. But directionally I expect this is where we will be going.