> There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model.

Yes, this is what I'm referring to. It's really many filesystems unioned into one namespace that is controllable per-process.

> In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?

I didn't say I had any issues, I said I preferred them! Aside from a lack of familiarity and needing to install plan9ports on other systems, I haven't had issues.

> In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server.

Right, language support is the biggest issue with running on Plan 9 from that perspective, at least for "server" workloads. Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends). The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.

> This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux.

This is also what Oxide is doing. Their rack's OS is IllumOS but their customers are expected to only interface with the OS via their tooling and instead provision VMs.

> It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment

If I were doing it, I would do it the other way! Run Plan 9 in a backplane/hypervisor and target it from the language level. The nice part is the systems programming model!

Porting Tailscale to Plan 9