We currently have TaskPriority::BACKGROUND for tasks that should be as little disruptive as possible and can take "an arbitrarily long time to complete".

The next priority after that is TaskPriority::USER_VISIBLE.

TaskPriority::IDLE would signify a priority that is lowest to schedule but must still run on a foreground thread when it is scheduled.

In issue 793069 we want to funnel multiple traits on a single sequence. To do so we can't mix BACKGROUND/USER_VISIBLE as when we only have BACKGROUND work, we don't want to move a to a background physical thread as that would cause a priority inversion if USER_VISIBLE/USER_BLOCKING work came in (the thread may be descheduled by the OS while we're blocked on it coming live).

In  issue 839099  we want to allow manually toggling the priority of a single sequence. Again, it could be reasonable to want not incur a priority inversion when doing this.

In the promises world (WIP) this would also be required. Ideally all services are initialized with IDLE priority and only promoted to USER_BLOCKING when actually needed before being loaded.

For all those cases, BACKGROUND->USER_BLOCKING promotion incurs a priority inversion if it's already running a background thread. Hence we need TaskPriority::IDLE

(I've also seen ad-hoc one off tasks that couldn't execute at BACKGROUND but were also disruptive at USER_VISIBLE priority)