Process priority got nothing to do with I/O priority, never mind that the concept of I/O priority as a single number, as it is usually implemented, is broken anyway. Eventually, you're accessing data on a spinning platter, and you're either going to get it on time if you have timing requirements, or you don't care much. No general purpose OS I know of is letting anyone specify this at that sort of granularity.
I don't get that so long as there is resource competition, you can't provide solid time guarantees. Errors are things you can't deal with, so it's a strawman: it becomes outside of OS's control. It's like claiming you can't do it because after all someone can yank the cord out of the socket. I do deal with industrial communication protocols that run on a controlled schedule and in spite of all the resource competition, things that need to happen at certain times do in fact happen that way. This extends all the way to allocation of computational and storage resources at the nodes. The storage resources are in fact scheduled based on queued data requests, so that in spite of bursts of activity, the scheduled transfers happen timely -- meaning that a read may be scheduled ahead of time if by the deadline other things would preclude it from happening. Same goes for scheduling writes, and for cache resources as well. It requires a different mindset when coding applications, but it works wonderfully, and you can keep those hard drives busy.