The assumption at the time the corresponding code was written in the C# binding (v1.x?) was that you would update the binding alongside the client library anyway (since there was a fast rate of release and new features at the time). And during the long hiatus, there were no new versions anyway so this wasn’t an issue.
This may be less true now that the code is more mature and that the rate of release as slowed down a bit.
The reason the .NET binding calls fdb_get_max_api_version and pass it back as the header version is because it would represent what the current client library was loaded at runtime. If the binding was newer than the client library, it would have to be careful and only call the old APIs, and if the binding was older than the client library, then the client library would handle emulating the older API surface.
I vaguely remember talking about that with someone a long time ago, but I can’t be sure if this is what was recommended to me, or if it’s something I improvised on the spot 
What do you mean by that? Do you require the correct header files at compile time? The .NET binding does not have this issue (dll is loaded and “inspected” at runtime) so that may be why I’m not having the same issues as you and went this route? Do you have any other way to interop with the library in a more “dynamic” way?
I agree, and this is a long-standing debate 
At the time, I was not able to ship the client library with the binding because of the closed license, but this is no an issue anymore.
I already proposed an API to get the version of a cluster in order to select / download the proper client library at runtime, but I’m not sure if this is being considered ( New API to get the version of a running cluster without needing a matching libfdb_c library )