Your question make have left some confusion about the nature of the problem you're seeing, but one of your comments provides a hint as to what's really happening.
We are currently explicitly restarting the server and set up the sync again from scratch
What I think you meant is, you're setting up replication from scratch...
In other words, it's not semi-synchronous replication that's breaking, it's all replication that's breaking. Like this, on the slave, right?
If that is the case, it is quite correct for the master to still report
ON. Here's why:
If semisynchronous replication is enabled on the master side and there is at least one semisynchronous slave, a thread that performs a transaction commit on the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has received all events for the transaction, or until a timeout occurs.
The slave acknowledges receipt of a transaction's events only after the events have been written to its relay log and flushed to disk.
http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html (emphasis added~sqlbot)
Semi-synchronous replication adds protection against transactions being lost by ensuring that they exist in the relay log on at least one semi-sync-capable slave server -- not that they have actually been executed by the slave SQL thread on that server.
If your SQL thread is stopping, this is a sign that you are not starting out with precisely-identical data sets on both machines, that you're misconfiguring
replicate-*-table variables, or that you're have something poorly-designed, such as nondeterministic queries against a table without a primary key.
But the status of the SQL thread on the replica server does not matter with semi-synchronous replication, since it is only concerned with the responsiveness of the IO thread, which is the thread that receives the binlog from the master, writes the relay logs on the slave.