Thank you for the PR!
The current implementation intentionally handles the out of date internally. The assumption is that the user has another mechanism of getting the signal of surface being resized (like an event from the window system), and that will make the user to recreate the surface. So "out of date" is essentially ignored, with a warning in the log.
We need to understand why this approach doesn't work for your Tiling WM.

@kvark how do I check why a surface is out of date without this change & is there any logging/debug I can look at to check why it is going out of date. Essentially if it's not a resize event but another event, the app gets stuck and has no way of fixing it

How about a new method that returns a Result and this method calls that method internally?

That way the signature is kept the same but we can still get the error out if we want to

I've adjusted the PR to include a try_acquire_frame method, but keeping the semantics/signature of acquire_frame intact

how do I check why a surface is out of date without this change

With current code, the only error that is not fatal is OUT_OF_DATE, in which case we'd return a "dummy" frame. Admittedly, the user can't know if it's dummy. We could expose a simple method, e.g. is_valid(), for the user to know.

The approach you are suggesting - via try_acquire_frame is fine. The only problem is that it's not platform-agnostic.
We'd either need to define an error type that is platform-agnostic and implement this for other backends, or we add "vulkan" somewhere in the function name to make it clear that this is backend-specific.

I've adjusted the method to be called vulkan_try_acquire_frame