It's not really the fault of MUD developers, more the obsessive nature of the players, who each have their own favourite client that is set-up exactly how they like it, and full of huge macros and plug-ins that only they understand. These players will not even try out your new MU* if it doesn't support their client.

I think it is the fault of the MUD developers, because they feel like they must support those players.

The group of people who play MUDs "traditionally" (with a dedicated, telnet-based MUD client) is small and shrinking every year.

The group of people who play lo-fi, retro-style games is large and growing every year.

Why give special treatment to the former group if it hinders your ability to appeal to the latter group?

> Supporting it as an option requires some kind of server-side content rendering layer which can be inherently restrictive to your other client offerings.

It should be no more restrictive than the concept of supporting text rendering at all--which maybe want to be able to avoid?--as, worst case, you could literally just run a text client on a server on behalf of the user.

It's restrictive in that it requires your content to be rendered as a continuous stream of text. That sort of rendering is not suitable for all text games that could be considered MUDs. It's not even all that suitable for the more popular MUDs that still exist.

Now, this is not a hard requirement of the telnet protocol, for sure. ANSI controls exist, as do various sub-protocols, but support for these is mixed across telnet clients and therefore can't be relied on (unless you're willing to say your game can only be played by a subset of telnet clients, I suppose).