Yes, supporting additional languages is straightforward; just need to write language-specific SDKs with bindings to the necessary Pax APIs, which are exposed through an ABI / FFI. (a major advantage of building at the systems level.)
Major constraints for a given language will be runtime size and browser viability — it's fine to use e.g. C# and the CLR when deploying a desktop or (arguably) a mobile app, but it's a showstopper to bundle a several-hundred-MB wasm runtime to ship a C# app to the web. Zig and C++ don't share this problem, and JS gets a freebie because the browser already includes the JS runtime.
Community contributions would be amazing in this regard. Likely our core team should ship JavaScript support first as a template, then Pax's language support should be roughly as extensible as e.g. Stripe's SDKs: https://github.com/stripe
C# does have WASM flavour, and several hundred (the runtime is actually very light, it's the whole SDK installer that weights this much) turn into a couple megabytes. It's not perfect with Mono-WASM target still, so there's an experiment for NativeAOT-LLVM that builds on top of .NET's IL AOT Compiler that is significantly more size and performance efficient.
Major constraints for a given language will be runtime size and browser viability — it's fine to use e.g. C# and the CLR when deploying a desktop or (arguably) a mobile app, but it's a showstopper to bundle a several-hundred-MB wasm runtime to ship a C# app to the web. Zig and C++ don't share this problem, and JS gets a freebie because the browser already includes the JS runtime.
Community contributions would be amazing in this regard. Likely our core team should ship JavaScript support first as a template, then Pax's language support should be roughly as extensible as e.g. Stripe's SDKs: https://github.com/stripe