Actually, "client" workloads (personal computers) aren't very parallel so the requests are served sequentially. As such, this won't help too much.
Most client machines don't have multiple drives mirrored either. I was thinking purely in a server setting when I made the comments, though I'll admit that I didn't specify.
A HD with two head systems still wouldn't match an SSD for random reads, but it'd be much better than one. Depending on the use it's seeing, it could even employ different algorithms depending on the use mode it's seeing to help speed things along. In addition, more cache might help it during a large sequential read, allowing the heads to leapfrog each other better. Like I said - engineering and programming nightmare, but an interesting thought experiment.
By the way, if I remember correctly multiple requests on flight were implemented on SATA standard for client drives, 10 years ago or so on (SCSI had them for quite a while). I'm not sure Windows XP uses these queues.
You're talking about how the system queues multiple data(read/write) requests with the drive, and the drive possibly delivering them out of order(because it's using an optimized path to collect all the data), right?
I assumed that capability from the start. The REAL trick to the system is that to date it's one read head per platter, thus one device serving all the data. With two head systems, the question comes up of how you optimally assign said demands between the two head systems to most efficiently move the data.