I hear what you’re saying, and I agree that this design requires non-trivial effort to support multiple versions of the database. I think a big part of the issue here is that our protocol between the bindings and FDB is defined using a C interface, which is not the most flexible or conducive to being modified. It is technically possible to write a client that dynamically chooses a header version for the C API (the multi-version client does this using dlopen and function pointers), but it is often rather painful to do and maintain.
If we had a better protocol, doing this dynamically could be quite a bit easier. One way to accomplish that would be via a proxy layer that provides some sort of flexible RPC interface. I saw a post a while back about an implementation of this idea, which possibly could be leveraged. I’m not sure if there are other similar projects being worked on in this vein that could help. You could even imagine having a very simple layer run locally per native client that wrapped the C API and exposed it in a more usable manner. The layer would have the same version coupling concerns you mentioned, but perhaps with a smaller amount of logic that maintenance would be easier than doing it for each complex language binding.
For the native client itself, I’m not aware of any plans that would significantly change its API to help here. If you had any ideas that you’d like to be considered, though, we’d be happy to hear them.