Following up on the remarks below
I think it is wise to consider Qu-Prolog’s wait mechanism on database changes. Found some docs on Qu-Prolog 10.3 Reference Manual - Built-in Predicates, search for thread_wait. Being able to wait for the database has some nice properties as it allows something (typically one or more threads) to update the world view while other threads act as agents, drawing conclusions and taking actions. Current SWI-Prolog isn’t very good at that. Qu-Prolog was built for that.
Acting on the dynamic database notably fits well with the recent incremental tabling and monotonic tabling additions.
First I found an older version of the docs discussing thread_wait/0,1. I think that comes from the days that Qu-Prolog used cooperative threading as it cannot work using preemptive threading as the condition may be fulfilled between deciding it is not fulfilled and waiting. They added thread_wait_on_goal/1,2 which moves the goal to test whether or not to wait inside the predicate, so the whole thing nicely maps to POSIX condition variables and is reliable.
I think the spec is pretty much ok. I’m planning change wait_for(Secs) to be compatible with SWI-'s related predicates that accept timeout(Stamp) and deadline(Secs) and add an option to wait for a module as that seems an attractive simplification between waiting for any dynamic predicate and a list of specific ones.