This question has come up a few times before and in connection with other nodes as well, and I think the issue is what Nick describes. My guess is that if there were an easy fix for this in the runtime, it would already have been done.
For the gate node in particular, the status is set before any input is received, and I recall either @knolleary or @dceejay having checked the code and given it a clean bill of health, although I can't find the post at the moment.
I have a kluge you can try while I implement a workaround. You can replace the gate node with the q-gate node, which operates in essentially the same way if you ignore its queueing functions. One difference, however, is that I recently added a status command to q-gate that causes the node to refresh its status. If you connect the node to an inject node that sends the status command on startup with a short delay, you should have the flow fully deployed and the status node ready to accept input. I happen to be working on a bug-fix release of the gate node, and I should be able to add the status command and publish it in a few days.
