multi-benchmarks.el

• mu- is a pretty bad namespace prefix due to confusion with mu4e (where the native parts are known as mu).
• Use cl-lib consistently, cl-lib-hightlight helps.

multi-methods.el

• Please don't do lexical binding hacks, instead use it in all files you write. A template for them can help. Tell people using your library likewise.
• concurrent access can happen in process filters, irc.el has an instructive comment: https://github.com/jorgenschaefer/circe/blob/6ccd4b494cbae9d28091217654f052eaea321007/irc.el#L122-L133
• Comment headers of the ;;* foo --- *;; variety are anything but standard. Use ;;; foo instead and check out the coding guidelines in the reference.

multi-patterns.el

• Yes, interactive is special, it can accept code that will be evaluated at a later time. No idea about declare.
• Consider using buttercup if ERT causes you massive pains.
• Mutating list literals is a bad idea in any case, don't do it: https://web.archive.org/web/20170106022314/http://shift-reset.com/blog/2014/2/28/List%20Mutation%20Public%20Service%20Announcement/
• ? doesn't translate to 32, it's char syntax for a space (which is better expressed as ?\s anyway). You'd be better off escaping the question mark instead, that would make it a symbol.
• Generally speaking, consider not translating mu-patterns to pcase and roll your own thing instead. This would be a greater undertaking, but teach you a lot more and most certainly avoids degenerate pcase cases. There are a bunch of implementations in Emacs Lisp, Scheme, Clojure, the better ones reference papers.

multi-prelude.el

• This file will most certainly not fly because its unprefixed stuff goes way beyond shimming. MELPA's packaging standards are pretty strict here.