At the risk of being flamed, I must say the following...
Microsoft has a great idea with their Interface Contract idea. They will create an interface (API) with certain methods and properties; then they will update the interface with new methods and properties WHILE RETAINING THE OLD INTERFACES.
I suppose some API's in Linux are using this model for backwards compatability but all are not. The idea has good and bad points: good are that old programs will keep running; bad are that api bloat will occur.
Choose yer poison.
Microsoft also had another good idea back in 1994: minidrivers. MS realised that alot of the monolithic driver code in Win3.1 was similar if not flat out identical. The only differences were the device specific portions. Therefore, MS implemented the stub (or whatever they call it) that contained the generic code for a device then the minidriver made by the device company completed a full device driver. Simple, easy, concise.
There may be reasons why one would not want interface contracts and stub modules; at this point, I don't see much of a reason not to have them myself.
Now for the Driver on Demand idea - I think it's good. There could be a central database possibly at the distro maker's site. It could contain minidrivers for each device (submitted by the device manufacturer) with each device having an ID (I assume they already have this ID) and a database onboard the user's computer to complete the identification and driver selection process.
Compilation on Demand could be a boon AND a bust depending on the accuracy and testing of the builds. I use Gentoo so I'm comfortable with this model - others may not be.
There's my buck fifty,