M109 behaviour

I've been putting off implementing the M109 G-code in my Redeem "firmware" because I'm at loss about how it should be implemented.
Judging by the text on the G-code wiki page about this command, I'm not the only one at a loss

So "set temperature and wait", does that mean block all other G and M-codes until the temperature has been reached?
If so, it's not possible to monitor the temperature. A different interpretation would be to return "ok" for what ever protocols require that
and then continue execution of following g-codes, but halt all G-codes related to stepper (cached) movements (G1, G28, G92). If the latter is the case,
would the cache then not fill up eventually, and then block any immediate G-codes such as M105 (get temp)?

This subject is perhaps related to a different issue of interest. Because there are several electronics boards that now have Ethernet connections something that has
caused Pronterface to not add CRC and check for return codes since this is handled further down in the IP-stack. I have addressed this issue
to the Pronterface maintainer(s) and apparently iXce agrees it was perhaps not well thought through. A virtual null-modem connection
for communication with Octoprint running on the same board will also face the same problem. Without return codes, the buffer fills up very quickly
leaving an array of some 100 pr more G-codes top be executed while blocking any unbuffered codes (M105 for instance).

Any comments on this? Or perhaps even a solution?

You don't need to monitor the temp when you send an M109. The firmware (at least Marlin) periodically reports the temperature - all of them actually - bed and all hot ends - and their target temperatures too.

Ah, so the command blocks other commands, but periodically returns the temperatures? That seems to solve it, yes, I'll try that!