Thirteen windows created, four mapped, three of them containing ONE UNIQUE COLOUR across every pixel. Those three were the flat rectangles over the document, over the sidebar and the band straight through the middle of the page. They were never drawn because the application never showed them; they were on screen because this backend mapped them anyway. present() is reached from flushBuffer, from makeKey, from setTitle and from half a dozen other places, and whichever arrived first attached a buffer and committed. An application creates windows long before it shows them, and LibreOffice creates plenty it never shows at all. FINDING THE REAL SIGNAL TOOK TWO WRONG TURNS, and both are worth recording. It is not showWindowWithoutActivation: that is what setIsVisible calls, LibreOffice never reaches it, and gating on it alone mapped NOTHING. orderWindow:relativeTo: sets its own _isVisible directly and then calls placeAboveWindow: on the platform window, which this backend implemented as an empty function. That is the signal. showWindowForAppActivation: was a no-op too and now shows. WAYLAND HAS NO EXPOSE EVENT. X sends one whenever a window needs its contents and the X11 backend draws from that; a Wayland client owns its buffer and has to know when to paint. Newly shown and newly resized windows are marked for display explicitly, from the main loop rather than from a compositor callback. Result: one window mapped, with 3358 distinct colours in it, and a document window with no holes. WHAT IS STILL WRONG. The chrome around the page, the sidebar and the status bar are painted in a wrong colour, and it still looks like an uninitialised read: within a run those regions share a blue byte exactly while red and green differ, and the values change between runs. That is a fill with a bad colour, which is a smaller and different problem from a window nobody ever drew. No regressions: nested sway still delivers clicks and keys, and the probe still types hello into both an NSTextField and a modern NSTextInputClient.