What I care about is the state of the work I have done. And no, 1) writing an editor from scratch is difficult 2) having an editor built on top of your MUD has the great advantage over standalone applications, because that way the editor is always up to date.
You entered the world of viral licenses with Diku, it is kinda like the GPLv3:better not touching it even with a ten foot pole if you dont want to be assraped by Stallman like zealots hehe. I differ with the point 2 though: an editor can be agnostic of the output file. If your mud need another option, you will put it in the editor anyway. So the graphical editor itself can be totally standalone and agnostic of the endfile, and all the specific work considering your mud can be in the output filter (it is a hard work yes) but that is why you always separate graphical input and data. Need another exit flag in the editor ? -> need to update both graphical editor to show it, and output filter to save it anyway. So they will stay up to date with your mud, standalone or not.
My MUD reads area files into data structures and keeps those in memory (I know, that's very standard). My MUD is quite old so the file format has changed a lot over the time, but it can read any possible format version from the latest back to the one used in the original codebase. Moreover, being able to read pretty much anything that I would possibly care about, it can also save areas in the newest format it knows, working in kind of a converter mode. So at this stage I don't see any need for filters, whatever you meant by that.
So when I want to add a new room flag, along all things I have to write for it to work (from the game's perspective), I also add a new entry to the table of room flags so that it can be used by rstat command. My editor uses the very same table to automatically create checkboxes for room flags in the room edition window. So when I'm done writing stuff for the server, I have the work for the editor already done as well. Sometimes I have to re-work logic in some part the editor, but most of the time it's just a matter of creating new widget in Glade and hooking it in the code.
Another example. My MUD has descriptions and extra descriptions for rooms and descriptions for mobs and objects. But objects used to have extra descriptions as the only way to describe an object. It's never been a big deal for anyone - builders were writing descriptions of objects in the form of extra descriptions and players were able to look at objects and see those descriptions. But in the process of developing the editor, we have noticed that it didn't make too much sense and would have complicated editor's interface. So it's been decided to create a new mandatory field description and get rid of extra descriptions for objects. Work has been done to reflect that decision, and when it was done, the MUD was able to read objects in new format, store their descriptions in memory and show them to players. From the editor's perspective, it was just a matter of adding a widget and hooking it in the code so that it could read/write data from/to memory.
One last example. I write a bunch of new spells, object materials and races in the server code. There, the game supports all of that now and so does the editor. Once that stuff is in the shared code, you can use it in the editor: mobs can use new races, healers and wands can cast new spells, objects can be made of new materials. I don't have to update anything my editor.