Your description makes it sound like a regression but FILE thread was just
a worse version of that, right? i.e. *all* of the file work in chrome was
sequenced regardless of priority and need for sequencing. Now at least you
only share sequencing with same context tasks. I agree that being able to
have multiple priorities on the same sequence would be nice but it's an
improvement request on the existing improvement.

Agreed?

Yep!  This isn't a regression, just a request to make it all even better. :)

On a semi-related note, if we want to run all file-related work at "roughly what it was before" (i.e., to avoid slowing down user-blocking flows like extension installation and accepting that other flows like garbage collection will be no worse than they previously were), is there a preferred priority?  Said differently, do tasks posted to a named thread (like FILE) run with an implied priority?

USER_VISIBLE is the prefered default priority. BACKGROUND is actively throttled and USER_BLOCKING tries to jump ahead of everything else.

Named threads pretty much all had USER_VISIBLE implied priority (weren't throttled at the OS level but couldn't preempt other work either) -- even BrowserThread::FILE_USER_BLOCKING was the exact same priority (just had fewer things in its queue...).

What is needed here is Sequence Funnelling (a feature being considered by TaskScheduler)