rmoo VS EtaMOO

I've done the "whole new thing" before, too. 20ish years ago, tho I only have a few fragments of what I worked on back then: https://github.com/rdaum/mica being one of them I found on an old drive. Not complete.

But sticking with compatibility has allowed me to enforce development discipline, basically. And then I'll move it onwards from there.

Re: world state / transactions -- yeah, basically all I/O and mutations happen in a transactional context, and then at commit time conflicts are resolved; if they're not resolve-able, the transaction is retried in a new state. As for overhead, yes potentially maybe a lot, but it's also a solvable problem; this is how an MVCC SQL database (like, even Postgres) works. TLDR it's likely inefficient now, but I believe I can make it efficient. And I think it's the best to solve the shared world state problem and still meet user's expectations of consistency.

Re: the MOO client, it's `rmoo.el`: https://github.com/lisdude/rmoo -- it's been around for a long time (25, 30 years?) and it and/or MOO.el (another emacs one) are how/why I learned emacs in the first place. I had to patch my local copy to make it work with emacs 29.1.

A friend of mine maintains a fork of RMOO, an Emacs MOO/MUD client. You might find it interesting: https://github.com/lisdude/rmoo

Good luck. As someone who used to work on a lambda-derived MUD it's great to see a little life left in that community. The original server was horribly outdated even 20 years ago.

I also found this project randomly on github at one point, not sure how far along it got to being usable: https://github.com/verement/etamoo