That'd be my company. We've had Zig in production for more than a year now, and it has gone remarkably smoothly - if you're ever using public transport in northern Europe or Germany there's a non-negligible chance that there's some embedded device running Zig code in it that's logging GPS and route data.
>I believe there is someone using it in production for a field deployed embedded system that is tied to revenue.
Sure. But people do all kinds of not advisable things, even if revenue is at risk.
In fact, it might even be fine, for their use cases. The build it once, it has the libs they want covered, it works like the want, that's it.
That can work with any early release language/lib.
The problem is with someone casually putting it into production, and then not expecting breakage, missing libs they will need, finding that there's not much tooling, and so on.
In other words "can it be put into production?" is another question compared to "is it ergonomic, stable, full featured enough to be a good and easy production choice?"...
Almost everything can be put into production (and even work reasonably well), even a 1000-liner Perl script written by someone who first tried Perl that same week.
Zig's C interop means it can leverage some of the most battle-tested libraries out there, with no shortage of libraries given C's massive ecosystem. And with Zig, it's not like you have to rewrite your whole system in a new language, you can incrementally rewrite the parts that make sense, test, and repeat.
Zig's tooling around compilation is also arguably ahead of most languages, and Zig's progress here is flowing back and adding value to many communities. For example, this 0.9.0 release can now build native Node addons without requiring node-gyp.
IIRC Forwards compatibility is not an issue because those deployments are one-and-done.