IBM ADO.net data provider version compatibility

Because my company is a software vendor, IBM's unfortunate habit of frequently changing versions on their ADO.net data provider is creating big issues for us. I assume that there are other ISV's out there who write .Net applications for the IBM i, so I'm hoping someone has worked out a way to tackle this. I have asked IBM, but still don't have a response.

To recap why this is creating issues for us:
With each of the last three releases of the OS (V5R4, 6.1 and 7.1), the corresponding data provider version has changed. While I am not a .Net developer myself, what my .Net developers tell me (and this is supported by what I found on relevant forum threads) is that when IBM changes the version number it breaks any .Net application with an ADO.net interface which wasn't built over that same version of the data provider. I grant that version induced breaking isn't unique to IBM's .Net components, and sometimes you really have to introduce changes that require a new version.

But - while Microsoft's .Net framework itself allows you to have multiple versions of the same installed and applications built over different versions of that framework can coexist on the same PC as long as the version they need is installed, IBM i Access does not allow for concurrent installation of multiple versions. To test or develop with different versions, we have to uninstall and reinstall the whole shooting match or use virtualization. Another very annoying issue is that IBM will only ship you new versions when you're ordering hardware or updates so my developers don't have free access to the various versions.

What I am faced with is these choices:
- dictate to the clients who use our software that they run a specific version of IBM i Access so that we only have to create a single version of our .Net software. This really isn't an option for us - hopefully for obvious reasons.
- create and maintain multiple ADO.net version specific versions of all of my .Net software for the various versions of IBM i Access that we need to support. I'll pursue the final option before this one.
- figure out a way to create an intervening layer between our applications and the ADO.net data provider itself. Where programs need to use ADO.net functionality, they will interface with this component instead and then that component will determine which version of ADO.net is installed on the PC and translate the request into a version-appropriate interaction with the provider. This is what we're most seriously considering - but I think it simply shouldn't be necessary at all.
- scrap using the ADO.net data provider completely figure out other ways to do what we use it for.

I'm hoping that somewhere here I'm wrong (as in there really is a way to have concurrent installs of different versions of IBM i Access or IBM has some sort of backward compatibility solution). But short of that I think there are no choices which aren't ugly ones.

It's difficult to understand why IBM would impose this sort of limitation/difficulty - particularly when the hallmark of the IBM i has always been that applications written for it dating back to its inception have required next to no maintenance at all for reasons due to operating system changes. Other than requiring our clients to stay within a couple releases of us so we can compile to the lowest level of the OS that we support and a few rare cases of avoiding specific PTF's/IBM i Access versions, we've never had any need to dictate to them that they run any specific release.

Help!