Guys,

Lets not start that fire again, from my experience mostly innocent people gets hurt from it.
As someone new to DVB implementation who joined the ride when both S2API and multiproto are already available I see some benefits and drawbacks in both of them. From my perspective I see S2API best benefit is the 'API' itself and its flexibility, while multiproto has its respectful 'flight hours' and more implemented features. That's probably a matter of time and efforts while more features will be implemented in S2API that will make everybody happy.
It was decided already to move to S2API and as I see from the lists and patches flying around many people are very interested in it.
We probably all agree that S2API is not mature enough for all the cases.

I didn't look in the VDR code yet, but I think it might be a good idea to have a layer that will handle the interface to the device and hide all those changes to the rest of the application. Since VDR is written in C++, that shouldn't be too complicate to achieve. And will allow easy switch to S2API (or any other in the future), while still maintainging the multiproto interface.

Regarding the resource decisions:
I see a strong point to move the decision to configuration file and not rely only on device reported capabilities.
Here is an example:
Several cards are in one PC, all DVB-S2 from different vendors, while one of them is not that good handling S2 streams (lets say a driver problems that suppose to be resolved), so the user might want to force that card to be used for DVB-S channels only, regardless the reported DVB-S2 support.
To get even further with the example, stb0899 cards are known not to lock on all DVB-S2 channels and not work well with different symbol rates, so I might want to have per-channel decision configuration so those problematic channels will be handled by another card, while all other DVB-S and DVB-S2 channels would be handled by all cards.