Accessing a union’s payload causes a panic

My guess is undefined. Did you look at that value using a debugger?

A safety check produces invalid enum value when switching over an enum containing an invalid value.

Union-field access performs safety checks too, apparently using a switch, judging by this error message.

As why17 suggested, the union probably holds undefined, which would make its tag undefined too.

From reading through that part of the code, I don't see any unions involved here, the selected backend depends on the os and the target that you are building for at compile time.

After wio.init is called, that backend ought to be initialized (or initialization should return an error), whereas before wio.init runs (and calls backend.init(options)), its backend values have not been initialized and their default values are all undefined at that point:

https://github.com/ypsvlq/wio/blob/dd0f273fdbbd1ced2a8e716ea3a5526a6c4d83cf/src/unix.zig#L20-L98

I'm puzzled by the library's heavy reliance on singletons and container-level variables initialized to undefined, I dislike that enough that I'd probably choose a different library.

Rather than delegate to its backend, wio could store the statically selected backend in a field of an ordinary struct, avoiding a singleton whose backend exists in an unusable state before being initialized.

It looks excessively focused on concealing details from the API by using globals everywhere.

I'm referring specifically to unix.Window, a union containing wayland and x11 implementations.

What escaped me completely was that the error originates inside a resize event callback, which apparently runs straight away during Window.init, and I'm reading from the very variable which is intended to contain the window currently being initialized, so that would account for the problem I am seeing here. That's… another design choice I'm not especially keen on either, though I havent discovered any decent alternative libraries.

It seems rather curious that accessing the union specifically is where it fails, when the window variable itself contains undefined, wouldn't reading its .backend member already fail before that?

A debugger run together with a printed backtrace ought to clarify the precise location and cause of the failure.