This would also be easily solvable in userspace if we had a DVB library that all DVB programs used (like ALSA has). That would also have other benefits, like DVB apps not necessarily having to do all the complex parsing of event/service/etc information tables themselves, which is a lot of code.
This could maybe be part of libv4l...
BTW, regarding the VDR part of the article: A network client for VDR already exists as a plugin (e.g. streamdev), so that is not the problem.
From what I've seen, people (including me) only have an issue with the fact that VDR is designed to run on a standalone HTPC with a single display output, and setting up multiple clients running VDR relying on one "server" instance of VDR is somewhat tricky (e.g. timers/recordings/channel lists of which every VDR instance has its own idea, unless using more hacks). Changing that would be a lot of work, but I don't think the VDR maintainer would refuse integrating good patches (like the article seems to suggest).
However, the above problem is not solvable by this vtunerc driver. One still needs to have some server application serving the vtunerc DVB device. If one uses VDR, one could just develop such a server application to serve some VDR client plugins directly, which would work just as well, and without kernel involvement.