@antirez there are a few things that came up and we'd like to run by you.
Maybe we'll open separate PRs or issues for them once you give some initial feedback.

1. There are no module APIs for RESP3, e.g. addReplyArrayLen vs addReplyMapLen
2. There seem to be nowhere that documents the meaning of each ACL category (in the code), this means that we might one day interpret @admin as having one purpose, and the next day as something else. for instance, does @read means anything that's not @write what about commands that don't read from the keyspace, should they have @read or not?
3. i'm not sure that TIME, LASTSAVE, ECHO, ROLE, should have the read-only flag (they don't access the keyspace)
4. I think you should go over the module APIs that are marked as experimental, and move many of them outside of that block (no longer experimental).
5. srandmemberWithCountCommand sometimes calls the old dictGetRandomKey (not the fair one), is that on purpose, or was overlooked?
6. when config.c enables AOF, it immediately starts an AOFRW. maybe we want to have a similar thing when the save config is changed? i.e when it changes from nothing to something, trigger a bgsave implicitly?
7. don't GEORADIUS and GEORADIUSBYMEMBER need use-memory flag? (like SORT does)
8. recently in DISCARD should not fail during OOM #6401 we fixed a bug with WATCH and -OOM, i now realize that the same bug will happen with other errors that return from processCommand, such as -MISCONF
9. We noticed that expire.c calls trackingInvalidateKey, why doesn't evict.c do the same? also don't both of these need to call signalModifiedKey? (to invalidate watch too)
10. An idea came up to consider changing addReplyDouble (or add addReplyLongDouble) to use "%La" format, so that it doesn't lose precision (like we did for RM_SaveLongDouble).
11. In the past we discussed a module API named RM_KeyExist, if we want to add one, should it be based on lookupKey (which does implicit expiry attempt) or dbExists (which doesn't, in which case a follow up attempt to open the key may fail)
12. I think we may want to add module hooks for fork. i.e. like atfork, one before the fork in the parent process, and two after the fork in each process. i suppose that these should be called with the GIL unlocked, so that modules with threads doing jobs can drain their job queue before the split happens.
13. similarly I think we may want a module hook before redis iterates on the keyspace (e.g. foreground save, debug digest, etc), so that modules with threads can drain their job queue.

If you can please provide a short response for each telling me how you'd like to proceed with it, fixing yourself, rejecting the topic, or asking that we'll open a PR or a separate issue.

Thanks.