If there existed a Squeak VM which had true concurrency and could use multiple cores then a high-priority process would not necessarily preempt a lower-priority process in the first place and hence ensuring fairness would require additional implementation work.  Essentially if and when Smalltalk VMs do move to true concurrency and multiple cores the scheduler will have to be rethought and rewritten and it would probably be a good idea to take the line Igor has with much more control at the image level.  Note that fundamentals like Processor activeProcess would no longer work.  One would need e.g. a pseudo-variable thisProcess.

But for the moment no such Squeak VM is in existence.  Those Squeak systems which do use multiple cores, Igor's Hydra, and Sam and Dave's Tilera64, replicate images so there are many green-threaded images networked together.  In this context ease of synchronisation can still be important, in fact possibly more important (see the server use case earlier in this thread).

In any case, if preemption does not imply a yield I don't see that this in itself prevents the use of multiple cores.  I'm working on a multi-threaded Cog which only switches native threads during FFI calls.  This VM can use multiple threads for as long as an FFI call is in progress, during which another native thread will run Smalltalk.  There are many ways to skin the multi-core cat.

best

Eliot