Programmer as well, and I agree with your general rankings in feasibility.
I think #3 is just a little bit too dwarven for me unfortunately, networking games by sending input and requiring all clients to be able to generate bitwise identical output requires a huge amount of design work from the start. Matching up the PRNG is one (probably nearly impossible) thing, matching up the PRNGs on multiple platforms using different compilers between different versions, dealing with floating point rounding garbage as the result of compilers changing adds to multiplies and being unable to rewind the world to reorder inputs from multiple players, and thus forcing a lockstep input iteration (with huge lag as it gathers all input for a round), does sound dwarvenly infeasible, and not in the "just needs more magma" kind of way. Then of course if there are multiple threads in the simulation (even if they don't share the RNG), you can toss any hope of bitwise identical output out the window. Considering how often one bit is the difference between your legendary hero murdering a dragon and your legendary hero dodging the badger and falling off a cliff, I'm don't think approximation solutions with constant resynchronization is at all feasible. Put another way, DF is completely non-linear, so basically any approximation is going to fail spectacularly. You need the bitwise identical for this approach, and I'm gonna go out on a limb here and say it, it can't be done.
PROVE ME WRONG, I DARE YOU.#2 is quite feasible, and has basically been demonstrated by DFTerm. Attempting to sync all game data is an impossible waste of time, but sending over screen captures (or the visible 2D world data for a given camera location) is simple. Further, queuing up input from multiple users, especially when input can only be given while the game is paused, is ridiculously simple as well, save for the one minor nuisance of 2 people giving commands to the same dwarf. That's just a policy question, and can be resolved by whatever mechanism desired. Grabbing the 2D world for a given camera location has been done by several of the memory readers, but even failing that, you can have the server move to the player's view, take a snapshot, send it, and move to the next player, so long as we don't really mind our 1FPS, that should be fine, and easy to improve upon. Sadly, I've never gotten DFHack to work on my Mac, so I've never finished any of my grand plans to implement multiplayer DF. If you can get DFHack to work on my mac, I'd even contribute a nice 3D rendering of ascii letters for your client UIs.
#1 is in many ways the most interesting, as #3 is nothing more than attempting to apply first person shooter or RTS (more RTS if you're going lockstep) style networking to dwarf fortress, and #2 is trying to apply a somewhat customized multi person remote desktop app (check if one of these exists, would probably be faster than writing your own), but I think is unfortunately just as impossible as #3, assuming of course you actually want to generate a consistent world. If thats the goal, you should be able to think of #1 as trying to apply database consistency rules (... ACID I think... atomicity consistency isolation fuuuhhhh.... dwarfiness?) or other multithreading primitives to dwarf fortress's PRNG. Running an entire fortress to completion is too darn long a transaction, is not atomic with other fortresses (assuming this is actually multiplayer, not a save game repository), should be consistent in and of itself, is -mostly- isolated from other fortresses, assuming your master embark dispenser, and I've completely forgotten what durability is, so lets just say that every fortress is very dwarfy, and thus has a durability of not so much (If my game crashes, you need to stop it from crashing your master history, even if I accidentally turn all my dwarves into elves with 8 arms that breathe firebreathing badgers that can raise the dead).
You can only have a truly consistent world if you can guarantee all four of the ACID rules, and as you noted, you can't.
I see no solution to the isolation problem: While the history culling may be able to restore some sense of sanity after the fact, I don't think its very dwarven if the dragon that burns my fort to the ground happened to have died 8 years ago, 5 years ago, and 2 years ago, in various other fortresses, unless of course it was an undead dragon. While the idea of guaranteeing isolation by forcing usage of different world sites would be perfect when nothing can move between sites, things can move between sites, and even if they couldn't all that would result is numerous disconnected fortresses, each exactly as playable as any save game.
Since we can't have consistent histories without major rewrites by the history rewriter -- hereby known as The Historian -- I would propose giving up the idea of a master server with a single world altogether. Hear me out.
The #1 you are suggesting did not sound like an MMORPG to me, it sounded like a shared save game repository -- There are a lot of fortresses, each created by one or more people over time. Each fortress can reference all (or at least some) other fortresses, but beyond engravings, cannot really interact with any of the other fortresses without all kinds of paradoxes for The Historian to resolve. Even engravings would be pretty hilariously paradoxical when you embark with historical figures.
So I would propose the following:
(--On rereading somewhere on page 2 or 3, I think you said you might be doing this already...--)
Just write The Historian. Two world saves enter, One world save leaves. Whether or not they have to be based off the same world to begin with is totally up to you. The history culler by itself is enough to allow every DF forum-goer to embark in a world with capn ironblood, Cacame, and 100s of mermaid bone artifacts, with none of the ridiculous synchronization issues you would encounter trying to force atomicity and durability on DF.
I can't speak to feasibility of The Historian, you would have to talk to Toady directly, but in terms of difficulty, it obviously reduces to solving #1, and is therefore more feasible.
tl;dr
#3 is batshit crazy impossible. Best of luck to you
#2 is trivial algorithmically, and has been demonstrated by DFTerm. It is just coding work, and most of it is work I can't do on my Mac if you intend to pass game data and render it instead of pre rendered snapshots. However, if you can get DFHack to work on a Mac(There is no /proc, you have to copy 4 bytes of memory at a time, makes it hard to do memory fiddling), I've been dying to write a quick 3D viewer for this game.
#1 is trying to force DF into giving shared histories in real time, but I don't believe the in real time is necessary. A shared history generator (known as The Historian) would be a better investment of your time, as it would allow the whole history of the forum to be referenced in every DF game. That said, its still probably impossible, but not as impossible as #3.