I'm not sure I understand what it would mean to have a single featureful scheduler.
There is already an abstraction layer built into YARN to allow multiple scheudling policies. Aside from the logic specific to the policy itself, the code for dealing with resource management is re-used amongst schedulers. That is, when someone is using the Fair Scheduler (vs the Capacity or FIFO scheduler) they are using mostly the same RM code save for the scheduling logic itself. Furthermore, several shared classes are used by both the Fair and Capacity schedulers, such as the Queue interface and the SchedulerApp class - these common classes are "tested" by users of both schedulers.
The alternative suggested seems to be having a monolithic scheduler class that can enact different policies depending on some configuration option. Any sensible implementation of that approach would abstract out the scheduling policy and I think you'd get what's already there now.
Or maybe the idea is that everyone using Hadoop will want the same scheduling policy (modulo minor configurations like timeouts, capacities, etc.). That seems unlikely to me given the diversity of Hadoop deployments and the fact that both of the currently available schedulers in MR1 are widely used.
Also, just a note - adding preemption to the capacity scheduler will not make it equal the Fair Scheduler. These are fundamentally different approaches which will become substantailly more different when multiple resource types are added to the YARN RM stack.
I strongly agree that having single implementations of common classes is a win in terms of support and testability - but I think this implementation mostly acheives that goal.