Hi, I now have perfectly clear in my mind what happens when issue #111 shows up. I don't know if the solution I'm proposing is the right one, this is a different matter. Moreover I might even be wrong. But at least I can try to share my understanding of the problem. When boradcastMessage is called it will 'get' the windowset, call handleMessage with the (against would be a correct expression?) layout of each workspace, and then update the state with a list of workspaces made up of the stack retrieved by the previous 'get' call, and a (maybe modified) layout returned by the *successive* handleMessage. The problem is that handleMessage may change the windows' stack in a workspace, if a call of 'focus' is made within handleMessage. This is what happens when you click on a decoration: the stack is changed *after* 'gets windowset', but broadcastMessage updates the state with an *outdated* stack, the one retrieved by 'gets'. The decorations, instead, reflect the updated stack that has been discarded. This doesn't happen with 'sendMessage' because sendMessage calls handleMessage with (against?) the layout of the current workspace. If handleMessage returns a new layout, then 'sendMessage' will call Operations.windows to update the state. And 'windows' will operate on a state retrieved *after* handleMessage returned, that is to say, with an updated windowset (and so with an updated stack). This is why my patch fixes #111 (as long as I can try with my simulated Xinerama setup - but I'm able to reproduce the issue with that very setup): it uses 'windows' to update the (Maybe) modified layouts (when it is Just) of every visible workspace. Now, as far as I understand, the use of 'modify' in 'broadcastMessage' is done in order not to call the resource intensive Operations.windows (there is no other reason *I* am aware of). But I think this wrong, because it is the only reason why a layout cannot safely call 'focus' in handleMessage. This is my understanding. Cheers, Andrea