I think the way you get closest to what you want, without creating an enormous long term maintenance burden, is to first build a good, stable API for FoundationDB clients in whatever the best widely available async RPC protocol is. You can connect to it with basically no client at all and (at the cost of an extra network round trip in latency) use FDB.
Then you write, in your favorite language, a wrapper on that that uses the locality API to attempt to route read requests, in particular, to the physical machine that actually has the data in storage, so that the extra network latency goes away. This latter step will still be tricky to get right, even if the RPC API is designed with this optimization in mind, because the client will need to keep the read-your-writes state if it isn’t sending all the operations in a transaction to the same server. So you will still want to integrate with FoundationDB’s simulator, which will be hard for some languages. But in principle I think a client built along these lines could be only moderately slower than the native client and only slightly awful to maintain
If someone was doing this successfully, I think I would support building the RPC API into fdbserver, so that there doesn’t need to be an extra service floating around and so that read requests sent to the right server can be swiftly routed internally without more serialization and transport overhead.