AW: "instead of going about it top-down and presuming the applications must be changed how can people change the OS to account for non-multithreading applications?"
The approach I've taken with ROLF is to start with the equivalent of the RO polling system, but extended it to allow new applications to make use of the underlying preemptive scheduling and asynchronous I/O from Linux.
Specifically, there's still Poll and PollIdle (called PollWait), which block the calling thread until the Wimp sends it an event, but there are also two more functions, Detatch and PollActive, which allow the calling thread to keep working while waiting for events from the Wimp. The former detatches the process from the Wimp so it can do anything non-screen related in the background and be informed of pending Wimp events by a signal (or selected file descriptor), the latter allows the process to continue working while waiting for the Wimp to authorise screen-related activity by the process. Also, screen redraws are requested of processes in parallel (one outstanding rectangle redraw per process).
Since the kernel is Linux, processes can also start threads, but the above allows a lot of flexibility without needing the complexity inherent in threads.