The only realistic way forward I know of is to switch the GUI daemon to use client-side decorations. This means that the GUI daemon (not the qube it serves!) would be responsible for drawing window decorations, instead of relying on the window manager or Wayland compositor. This will allow Qubes to work (at least to some extent) with any desktop environment, not just ones that have been made (either via patches or configuration) to support Qubes OS.
The difficulty with this approach is that it is a significant amount of work, especially since we cannot regress accessibility for disabled users. Accessibility is already a serious problem for Qubes OS, and making it worse is not something I consider acceptible. Generally, GTK has the best accessibility support, but the GTK developers are not interested in adding the hooks that Qubes OS requires. The only way to make the GUI daemon a GTK application, without needing patches to GTK, would be to use OpenGL for rendering. This would likely harm performance and is not something at least I am interested in doing. libdecoration will have a GTK plugin, but it is not accessible, and making it accessible would require patches to libdecoration, GTK, or both.
A completely new desktop environment would be significantly more work. If one could be made, that would be awesome, but I have serious doubts as to its practicality. This should not be seen as discouraging, but there is a huge amount of stuff that the Qubes team needs to do, so this would need to be a community effort for the forseeable future.