Yes, that is correct. However, I wanted to restrict this slightly to eschew the security and implementation complexity issues that you mentioned. I was requesting to be able to implement a set of fixed methods that follow some predefined fdb contract, and directly put them alongside fdbserver and load them in fdb process when bringing it up. Think of it as few more named operations like set_versionstamp_key, that are implemented by fdb users. Clients only get to choose the id of the predefined operation (and optionally some encoded params in key or value) at commit time.
I also tried to restrict the request to not get into any kind of filtering/predicate push down operations, as they have been discussed in detail earlier, and have their own set of challenges related to interfering with fdb caching.
Yes this is closer to what I was hoping for, for now. With one change - if users of fdb can implement these, as per some predefined contracts, and provide these to fdbserver as dynamic libraries when starting up.