Version 13 of exec on windows oddity?

MHo, 2009, June 20.:

Example-1:

         tk_messageBox -message "before"
         exec -- [auto_execok cmd] << {
                 notepad
                 sleep 5
         } &
         tk_messageBox -message "after"

With example-1, everything works as expected:

1. the start message appears - it has to be confirmed
2. notepad starts (this by itself is an asynchron process)
3. sleep starts (because thats a console mode program, a separate console window appears)
4. the stop message appears immediately (because the whole cmd is started in background with &)
5. after 5 seconds sleep ends
6. notepad is still running

The main window of the tk prog stays responsive all the time, because of exec ... &.

Example-2:

         tk_messageBox -message "before"
         exec -- [auto_execok cmd] << {
                 notepad
                 sleep 5
         }
         tk_messageBox -message "after"

With example-2, things are slightly different:

1. the start message appears - it has to be confirmed, same as above
2. notepad starts, same as above
3. sleep starts, same as above
4. after 5 seconds sleep ends
5. notepad is still running

At this point, the stop message still doesn't pop up, which is at first thought correct, because exec works in synchronous mode (without &). But: notepad has started in the background (so this step has finished), sleep has started and finished after 5 seconds, so why does exec not comes to an end??? The main program (at least its main window) seems to be in some indifferent state somewhere within the exec step, receiving input (windows goes to foreground) but does not redraw itself anymore, soon becoming an empty white box if obscured by other windows etc...

Only after closing notepad, the end message appears, and everything continues the normal way.