<- see that. i did just what you described above. 3 windows. 2 terminals, 1 elm test. i minimize elm test. i bring it back with alt tab. i bound an extra mouse btn to winlist next or winlist show- doesn't matter - same result. i can bring it back - wheel work s (though why use wheel when you are going to click on it anyway?)

Sorry, upload was corrupted

I do not think the window disappeared. its just below firefox. try just moving firefox out of the way.

But I don't see the problems you see (as you can see in my videos)... I can only imaging the window is there just below firefox... you know ctrl+alt up and down arrow raise/lower a window? you can lower firefox to see...

BTW your video looks a bit odd. it's very jerky... i see corruptions and weirs stuff... like:

Yes, the video has some artifacts due to your favorite NVIDIA GPU (I am alerted by the recording software, but I don't want to change the NVIDIA settings just for the recording).
As about window - no, it is not below Firefox. I can minimize all windows one by one - the first window is not shown. Even worse - if I minimize several windows - they are still not shown after focusing them by mouse-driven WinList, even after restart of E, I need to bring them over, one by one, using alt-tab, to access them later with mouse-started WinList.
It seems that for Enlightenment the window IS shown as in some tests I even lose mouse events in the window shown, like if they went to a 'transparent' window shown over it.
Is it possible to 'force' the redraw of this window?

well ... i can't see the problem... i really can't know what's happening - there is just so so so much code and logic that i can't even guess. it shouldn't disappear. I don't see this as an nvidia issue though - if the window disappears then the window really has gone - either e is hiding it or the app is - in this case likely e is hiding it.. but i don't know why - i don't see it happen so i have no idea how it gets into this state. if e thinks the window is there you should at least see the outline of a border/frame and the window content be empty if something is wrong with the client pixmap...

No, I don't see the outline of a border/frame.
Note, that just before closing WinList, when I select the window using mouse crollbar, it IS shown. It disappears when I click to close WinList. I think it is an important detail.
As I can see the problem, how can I try to debug it? As for now, this is the most important bug in the last version of E, I really want to get it fixed before updating the FreeBSD ports of EFL and E.

Heh... I could fix it!
I removed ~/.e directory and reconfigured E 'from scratch', after this I cannot reproduce the problem.
Raster, do you want to digg into my old config (I have a backup), or I close the task?

I see another thing changed in WinList since the replacement of E config - on change the active item in the WinList, the window of the item selected does not change visibility (before the replacement it was coming just behind WinList window, and I could see the content). It can be related to the problems I had.

oooh so something in config...

so can you do a diff of your config. i'm mostly interested in the core config so:

eet -d e.cfg config out.txt

do that to both your current e.cfg and the previous one and diff them? what has changed. the next might be doing the same to e_bindings.cfg .. i doubt anything in e_comp will affect this

The diff is huge, there are very many remembers in the old config (I did not set them manually!!)
The most interesting difference I found is some winlist values set to 0 now (they were set to 1):

value "winlist_list_uncover_while_selecting" int: 0;
value "winlist_list_focus_while_selecting" int: 0;
value "winlist_list_raise_while_selecting" int: 0;

I don't know if it is important.