Polling is typically a bad habit. You either have a far too long interval, not making progress or too short, wasting CPU cycles. This normally calls for a condition variable, but we do not expose these. Typically one waits using a message queue, but that doesn’t work very well in this case as when multiple threads wait on the queue, sending a message to the queue will only wake one. The GIT development versions allows asking how many threads are waiting on a queue, so you could send as many messages. This is a little dubious though.
Ciao, and Qu-Prolog have two things that are interesting. Ciao allows suspending on a dynamic predicate, causing a wakeup if some thread adds a clause. Qu-Prolog has a primitive to wait for any change to the (dynamic) database. I wonder whether we should implement some of this. The Qu-Prolog one could probably be refined by waiting for a module, so you can keep a set of relevant dynamic predicates in a module and wait for any of them to change. The Ciao Prolog one is quite closely related to SWI-Prolog message queues, but in this case does allow multiple threads to wakeup on a single event.
Could you elaborate a bit more on the use case so we can evaluate whether one of the above is sufficiently important to include it?
Retract on shared predicates is perfectly safe.