Thanks for verifying the test, Kristian.
I'm attaching a new patch (d5937-2a-close.diff) which attempts to fix the bug.
While a slave is running, LogToFile blocks in recover() waiting for fail-over to happen. When it is notified that fail-over has happened, it continues with ordinary recovery as a first step in booting the database, and in this process it reads the log files. In a "normal" boot process, the log file isn't already open when recovery runs, so recover() doesn't care about closing the currently active log file first. This causes a problem when promoting a slave database, which holds a log file open, as the re-opening of the log file will make LogToFile forget about the old file handle without ever closing it.
The fix makes recover() check if a log file is open, and close that file, before re-opening the log. It also enables the regression test case for the bug in ReplicationSuite.
I've verified that the test case passes on Windows when the fix is applied. I'm also running the full regression test suite on Solaris and Windows. Will report back when all the tests have completed.