This issue was bugging me a lot last week while preparing images for a presentation
with gimp... so I already started looking into the code on how to fix this.  As far
as I understood, floating windows are simply tagged to be floating while the (visual)
window stacking order is determined by the stacking order in the StackSet.  In my
opinion and as you said, the only defect of the floating layer is the lack of a raise
function that can be triggered either by mouse (raise-on-click) or by keyboard (just
to be consistent with the "keyboardless window manager" approach... although most
people would probably use the mouse in the floating mode...).

This could be done either by simply rearranging the windows in the StackSet or by
maintaining an additional ordered list of floating windows (which are not present in
the tiling stack).  The former approach has the side effect that a floating window
will not sink back into the same position where it was when set to floatig while the
latter solution is just... er... I don't know... I actually like the first one better
for conceptual reasons...

Unless somebody immediately know how to code this, I would be happy to implement...
but currently I am quite busy so I won't get on it before the weekend, I guess.

Cheers, Christian

I'd just like to suggest that you could experiment with an alternate floating mode by
writing a floating layout (which would make everything be floating) and then
combining it with a tiling layout using combineTwo.  You could then define
JumpToLayout keybindings to float and sink windows between the two layouts.  It's
slightly hacky, but would mean that your code could be put into contrib before it's
complete, so others could easily help out.

See also issue 4.

(No comment was entered for this change.)