...Personally, I like the fact I can still web browse without lumpy interruptions while a CD burns or rips, or when my mail client checks for new mail or usenet posts, or when I'm encoding my recent holiday videos, rasterising a printout in the background, updating the search database in the background, etc etc etc
Fair enough! I see what you're driving at now. I should mention that I'm using Windows XP and I do get lumpy interruptions while CD (or at least a DVD) burns, but I agree you can force the kind of responsiveness you describe using PMT. It shouldn't be necessary, though.
I didn't say there was no point in porting the OS, I just don't see rewriting the API for PMT as useful if the problem lies in scheduling within the OS or poorly written applications. For instance, I’ve never understood why so many RO applications hang the system when they rasterise a printout. My (very old) PRMs actually recommend calling Wimp-Poll throughout the print process, so either applications are ignoring the PRMs advice, or the Print manager is asking for the whole lot in one go.
I’m afraid I’ve not used a modern ARM compatible system, but I can see how recompiling code to take advantage of the target hardware, coupled with better memory management, would increase throughput. But I expect PMT to increase the number of context switches and that can only slow the system down. We may be talking at cross purposes. PMT is usually associated with block multi-threading, and that could certainly reduce bottlenecks.