I do lots of tech interviews, and I always make it clear that I don't care how pretty the ink looks. I stick with the whiteboard because it's the best way for candidates to explain their analyses and algorithms before they write the code.
I guess calmly evaluating my conclusions and approaching the problem with a third algorithm (I had already devised two and compared the answers) and then calmly asserting that my answer was in fact correct was the right move.
I do this sometimes. A strong developer would have a good mix of defending the design decisions made and the acceptance of the errors made. This test should bring this characteristic to the forefront.
You can get similar results without crossing that line by asking questions like "can this be made faster?" and "is this correct?", soliciting proofs of lower bounds on asymptotic complexity and loop invariants (respectively). But you shouldn't tell a candidate that their code is broken when it isn't. Interviewing is stressful and scary -- don't make it worse just because you can.
A mathematical proof on the lower bound? is that a common request and something I should prepare for in an interview?
"Ah, no wonder it didn't work!"
Then draw out an IDE around the code with a big [Compile] button.
Maybe even Clippy in the corner of the whiteboard. "It looks like you're trying to get a job..."
But that said, if you were interviewing someone and they did all of their algorithmic boxes and lines on the whiteboard but switched to the laptop to write the code, would you ding them for that?