I'll start with your last question first... mod_minimix *probably* still works with Prosody trunk (maybe even 0.11). But it is not much more than an experiment... of interest to client and protocol developers to play with, and not for general use. I think last I knew, there wasn't any way to leave a room once joined, for example (the whole point is keeping you connected to the room when you are offline).
Also note that despite the name, this module doesn't implement MIX! It implements one of the main MIX principles (join from your account, rather than from each device) onto MUC. The concept (as the docs explain) is to bring a MIX-like architecture to existing clients without needing any protocol changes. From what I know, it works, except for needing a way to figure out how to signal that you want the account to leave the room (remember... no protocol changes allowed!).
So that aside, let's talk MIX.
MIX is an entirely new (well, work started in 2015) protocol for group communication over XMPP. It originally started as an exercise in simplifying various aspects of the current MUC protocol. Over time it has grown in scope, and is now a collection of 8 different documents that describe various parts of MIX (some are required, some are optional).
As things stand, development of the MIX protocol has more or less stabilized, and we're at the stage where developers are producing early-stage implementations, but I wouldn't consider that it is ready for serious deployment right now. That is, unless you are starting a new closed XMPP-based project today, with custom clients, you may choose to go the MIX route if it covers all your needs.
But for the open federated network... it is going to be a long time before you can have a MIX-only channel and expect everyone to be able to join it, if ever. Unlike MUC which can be joined from any XMPP-compatible server, MIX specifically requires additional protocol support from each user's server. That means you can't just deploy a MIX server somewhere and expect anyone with a MIX-capable client to join it. We essentially need the whole network to upgrade before that is possible.
MUC<->MIX bridges are a possibility, and probably the only feasible way to get MIX out in the wild in my opinion. But at that point, clients will likely be implementing both protocols anyway for a long time.
There are also deployment issues to consider. With MUC the message archives were stored in a central place - on the MUC service. With MIX, each participant stores a copy of the messages they receive in their own archive. Server operators will be seeing a lot more traffic and storage used by users who have joined busy channels (even while the users are offline).
You mention the MIX support in other servers... Tigase's implementation is extremely new, and ejabberd's implementation is incomplete, it is lacking some of the optional parts of MIX and is incompatible with any(?) of the openly available clients.
As for Prosody, we actually had an initial implementation in 2015! But yes, today's MIX is almost unrecognisable, and we held off implementing it while it was going through such drastic changes. In the meantime we've been instead focusing on trying to incrementally improve MUC... the group chat protocol that is already widely available, implemented in practically every client and compatible with every deployed XMPP server.
Will Prosody ever support MIX? If someone contributes code or sponsors it, certainly. Otherwise... if MIX really gets adopted by clients (it's looking in recent months like it just might!) then I'm sure we'll support it at some point soon. But as MIX-only clients are unlikely to work outside of closed setups right now, it's not an immediate priority for us - MUC is already deployed and working for everyone, and still seeing improvements.
Hope all this answers your questions! Let me know if you have any more.