If you haven’t already, you might want to check out the section on watches in the Developer Guide, which has some amount of code. It is watching multiple keys rather than using a key to detect a change in a queue, but that’s about the same idea. That appears to be our only example of watches (really) in the docs, so maybe that could be improved.
You definitely should be able to use fdb.Transactor to set a watch in the same transaction as the one where you read the new data from the queue. That will close up the gaps in which you could miss updates if you had separate transactions for the two.
As @ajbeamon points out, you have to be careful when doing queue stuff that you aren’t accidentally appending things in the wrong order (or make sure that you can handle the out-of-order-ness). They don’t play well with the Tuple layer in go, but you might want to look at the versionstamp API to use transaction commit ordering instead of time to get around some of those issues. There are other issues related to queues due to the non-idempotency of queue appends, but maybe that’s a good question for another time.
One other note about watches is that you can only have a limited number (100,000 by default) of outstanding watches at a time. So, if the number n of watchers is small, that shouldn’t be a big deal, but if it’s large, you could hit this limit.