Fwiw it seems to me that it is not exactly overloading of the return value. That is rather input ambiguity which, unlike winapi MsgWaitForMultipleObjects, takes explicit queue handle as the last wait object which may also be absent.
wait_message(), as it is, has an API convention that matches WaitForMultipleObjects; i.e. it returns the index of whatever object was signaled, which is relatively straightforward. The "zero count" case breaks this convention, either before or after this patch.
Then if that is really an issue it would probably be more clear if we'd pass a queue handle to wait_message() instead.
That'd be another straightforward solution to this problem, but I don't know if that's correct to do in PeekMessage(). I can only assume it isn't for one reason or another.