waitUntil (JENKINS-25570) is useful when you need to poll for some external result. But there are cases where direct notification of a state change is possible, and this is more efficient than repeatedly polling. So there should be a wait step, probably with an optional timeout.

One use case is for a flow to await an event notification from an external system. To support this it would probably suffice to have an UnprotectedRootAction endpoint accepting POST requests (or even GET, for convenience); like /git/notifyCommit and similar endpoints, the event would be advisory, so the flow would need to verify that the event really took place:

while (externalSystemNotReady()) {wait()}

Alternately/additionally, the endpoint could require a specific event ID, request authentication, accept a (JSON?) payload, etc. You can use input for such purposes, but this is focused on human interaction, rather than REST calls from another mechanical system.

Another use case, which might be different enough to warrant a distinct step, is for one branch of a flow to notify another branch that some condition has been met and that it is safe to proceed; a kind of semaphore. This could serve as a generic alternative to JENKINS-26052 (fork/join):

def done = [:]
parallel a: {
  // do prep work A
  done.a = true
  notify() // wake up all waiters
}, b: {
  // do prep work B
  done.b = true
  notify()
}, c: {
  // do prep work C
  done.c = true
  notify()
}, d: {
  while (!(done.a && done.b)) {wait()}
  // do later work D
}, e: {
  while (!(done.b && done.c)) {wait()}
  // do later work E
}

Here the D branch could start as soon as A and B are finished even while C is running, whereas E could start as soon as B and C are finished even if A is taking longer, etc. You can already write

  waitUntil {done.a && done.b}

but a direct notification is preferable.

In order to support complex orchestrations, it would be desirable for notify to work across builds of a single flow, and across distinct flows in the system (assuming there is some way of communicating current state). It would even be useful to be able to support cross-master notifications, which is where this use case blends into the first.