Floating window issue when using wayland

Below is the output from Codex after having it crunch on a solution for a while.

Short answer: yes—for a production application requiring independent native floating windows with full drag guides and redocking, X11/XWayland is currently the reliable choice.
This is not because native floating windows are impossible on Wayland. The limitation is that the complete solution requires coordinated changes in both Avalonia and Actipro:
• Actipro’s Linux drag engine manually updates Window.Position and uses position changes to calculate docking targets. Actipro describes that approach in its Linux docking support discussion.
• Avalonia’s current Wayland backend deliberately returns no usable window position and makes Move(PixelPoint) a no-op in WindowImplBase.cs and WindowImpl.cs.
• Calling BeginMoveDrag would move the native window, but Wayland transfers the drag to the compositor. Actipro then loses the pointer stream it needs for docking indicators and redocking.
• Actipro’s public extension points cannot replace the relevant internal drag controller. An Avalonia-only patch therefore cannot restore the complete behavior while Actipro remains unchanged.There is a proper future solution: xdg-toplevel-drag-v1. It was designed specifically for detachable windows that become native top-level windows while normal drag-and-drop events continue to support reattachment.
I verified that:
• Your GNOME Shell 50.2 session advertises xdg_toplevel_drag_manager_v1.
• Mutter has supported it since version 48.
• Avalonia’s NWayland dependency already contains the generated bindings in NWayland.xml.
• Current Avalonia origin/main, matching your local checkout, still does not bind or expose it in WaylandGlobals.cs.
• Actipro would then need to replace its position-based Wayland drag path with the new drag-and-drop operation.
The protocol remains staging and compositor coverage is incomplete, so even a future implementation will need capability detection and a fallback.
For the current SampleBrowser, removing .UseWaylandWithFallback() from Program.cs will leave .UsePlatformDetect() selecting X11 on Linux. Note that UseWaylandWithFallback() only falls back when Wayland cannot initialize—it does not fall back when a required Wayland protocol is missing.
So the practical conclusion is:
• Supported production path now: X11/XWayland.
• Native Wayland with full Actipro docking: wait for coordinated Avalonia and Actipro support.
• Experimental path: we could prototype the Avalonia side locally, but completing Actipro integration would require Actipro source changes or an extremely fragile rewrite of proprietary internals.
The hosted workaround we added is Wayland-only, so it will not alter the normal non-hosted floating-window behavior when running under X11.

The Codex feedback is correct.  Our current v26.1.x releases were designed for Avalonia 12.0.  Wayland support has been added in Avalonia 12.1, but is still experimental.  We are planning to support Avalonia 12.1 with our v26.2.0 release, although Wayland support will continue to be experimental.  We have previously spoken with the Avalonia team about Wayland support, specifically our Docking product, and they mentioned some of the same issues Codex summarized.

Ultimately, it simply may not be possible to fully support drag-and-drop with Wayland because we have to be able to monitor the pointer position during a drag, and Wayland does not (to our knowledge) expose that.

On Windows this is all very simple.  We can start an OS-level window drag/move and poll the pointer position during drag to know where dock guides should go.

On macOS and Linux (X11) we cannot use an OS-level window drag/move because we cannot poll the pointer position after the OS starts a drag.  Instead, we have to emulate a move by tracking the pointer click/drag scenarios and manually adjusting the location of a floating window based on the releative movement of the pointer.

As noted in the Codex reply, Wayland does not let us manually adjust the position of a window.  We can't poll the pointer during an OS-level drag, and we can't manually reposition the window either.  Unless something changes, Wayland might simply not be able to support drag-to-float or drag-to-dock (from floating) capabilities.  Dragging to arrange within the host window could still be supported since we don't have to work with floating windows to support that.  It would be similar to the existing feature to using hosted floating windows.

We will perform more testing with Avalonia 12.1 and Wayland as we prepare our v26.2 release, but any Wayland support will continue to be experimental for a while.