I may have come across this behaviour in Emu on a different piece of software.
Does the demo poll the keyboard status reg in at tight loop waiting for a character, but simultaneously have an ACIA interrupt routine that reads the keyboard? The original of Leviathan runs into trouble with this scenario (but, oddly, not the Automation disk) unless you have a bit of fiddly-ness in the emulator.
I traced the problem to Emu only executing its timer callbacks (and, through them, receiving bytes from the keyboard) on instruction boundaries, which would immediately generate the interrupt and that would always be taken. However, if an app polls the keyboard, it can see the character is ready before the interrupt is taken, because the status bit can change in the gap between the instruction starting and the read being done at the ACIA. In addition, there can also be some MFP latency that provides a bit more of a window for it to be visible. (I fixed it by adding a method to execute a timer early in these sorts of cases; I need to add the MFP latency too at some point).
The symptom at the app level on a real ST (and on the emulator when you fix the problem) is that sometimes you bash a key and it's missed (because the interrupt catches it) but sometimes you bash it and it works (because the poll manages to see it first), which sounds like what you describe. Before fixing the problem, the thing just never sees a key and locks up.
It may be that STeem initially had the same problem Emu did (locking up) and later fixed it with either or both of adding MFP latency or cycle-granular receive, but it wasn't then realised that the patch was now no longer required?
So if you can verify with the debugger that it's polling in a tight loop I think there's probably nothing to fix, but as you say, can't hurt to check for the same behaviour on a real machine to be sure.