I don´t see why differentiating minimized windows would be useful (probably you and me works in different ways). Could you provide an example showing the advantages of your idea? I neither see the advantages of minimizing windows at the Overlay mode (other windows operation would be useful, but minimizing?)

Sorry if I sound rude, it is not my intention (but my English is not so good) and i ask this question because I guess you are seeing something I am not able to see.

(Relevant bug 604237)

To me, when I minimize a window, it means I don't care about that window and it should not get in my way. This does not mean much if you always have a maximized window on. But when you tile windows on screen (for comparing, cross referencing or parallel editing...), the on-screen window set (i.e. all except minimized windows) really matters.

I update bug summary too because metacity wraps minimized window titles with square brackets in alt-tab bar. gnome-shell/mutter do not (a regression to me).

Going to focus this bug on visually distinguishing minimized windows in the overview.

I think this may be interesting to try.  We have a few ideas and I'll try to get a mockup in the next day or two.

Created attachment 155163 [details]
mockup

Interaction notes on the attachment in comment 4:

Think of the workspace as being divided into upstairs (non-minimized) and downstairs (minimized). The screen is split only when there are minimized windows. Upstairs shows the thumbnails at the larger size as we do today. Downstairs thumbnails are smaller and dimmer (but still 100% opacity), since these are minimized. 

When the user hovers in the downstairs area, we should animate a swap in the treatment after a very short delay. So upstairs shrinks up to a smaller size, and downstairs is made larger. This gives the user a better look at the minimized windows. The line between these will necessarily move up in this case. This swap remains until the user mouses out of the expanded downstairs area or off of the workspace background.

Essentially, the larger set of the thumbs should follow the user's focus. This hopefully will enable users to more quickly choose a minimized window, while maintaining a visual distinction in the two sets.

We should consider allowing a user to drag a window from upstairs to downstairs or vice versa, in order to minimize or un-minimize respectively. While dragging like this, we should ignore the morphing described above. This interaction would be very helpful for heavy mouse users and touch interfaces. As described in other bugs related to drag and drop, adjacent windows should be animated to shift out of the way and gaps should be presented when dragging and dropping a window.

Now that the minimize button is not even there by default, perhaps the minimize option from the contextual menu in windows title bars should be just removed. Let's briefly analyze the current behavior of minimizing a window.

When you minimize a window, it disappears from the desktop with an animation that suggests that it went to the overview (and in fact it did). But the problem is that all your windows appear in the overway anyway and, despite all the discussion above, there's no visual distinction between minimized and non minimized windows in the overview.

Compared to the overall usage of the shell, which is clear and coherent, minimized windows are poorly managed. Their behavior is actually confusing. I think we should either remove the minimize option in the menu or make minimized windows visually distinguisable in the overview.

Jon, is this still something we are considering? We added some differentiation in the 3.8 cycle (on request of Jakub) and reverted it later (on your request) ...

Hard to know how to do this effectively. We tried it once and it didn't work out well. Also, we've rebranded minimize as hide, which makes it less pressing.

I think we should close, unless anyone can come up with a new idea. Thanks for the report; we did try!