I think that there’s a few things that make these ideas more appealing on MUDS than in standard pieces of parser IF. I’ve never done more than dabble on MUDs, though, so take what I have to say with a grain of salt.
A lot of the issues boil down to the fact that each IF game is itself a “separate program” in some meaningful senses. Each bit of parser IF is also run on an interpreter, which is a program that pretends to be virtual computer to run programs that are written for that virtual computer. This has several implications. One is the question of where you’re handling these features: in each individual game? within the interpreter?
If you’re defining aliases, triggers, and paths within an individual game, OK, there are few problems from an implementation perspective: each author just writes some code to implement these features. (Well, “just” is massive bit of hand-waving, but …). You can get around some of these implementation issues by including standard definitions of these features in IF-focused domain-specific languages, or by developing libraries that authors of individual games can choose to include in their projects if they want to do so.
But there are additional problems from the user experience perspective with the “each game implements its own macro-type features”: once you’ve defined a macro for Earth and Sky, how do you use that same macro with Earth and Sky 2 and Earth and Sky 3? What if the game’s author didn’t include any macro capabilities in the first place? If you can move the macros from game to game, how do you handle macros that don’t make sense in the context of the game to which they’re being moved because the play mechanics or details of the underlying implementation are different?
You might theoretically get around some of these problems by building the macro-related functionality into the interpreters used to play the games, but you have massive problems here, too. The interpreter takes a low-level view of each game, not a high-level view. The 'terp, at its most basic, is a virtual machine that executes bytecode to read and write text from a terminal. So a program that is, say, written in Inform and compiled to Glulx requires a Glulx interpreter, and that interpreter pretends to be a virtual computer and executes the game code. But what the 'terp sees is not the overall structure of the game in the way that a human would, but just a series of very low-level instructions at the level of assembly language: move these two bytes from memory to a processor register; add them to the two bytes stored in this other process register; spit out a string version of that number to the console’s text stream; dump this string of text to the same text stream right after the number; compare these two numbers to see if they’re equal; if they’re equal, branch off and run this other routine; … . It is a huge distance away from the author writing something like Every turn (this is the People Seek Their Goals Rule): let L be a list of awake people who are not nowhere; repeat with P running through L; ... (for instance) in (for instance) Inform.
The problem with at least some of the macro-type functionality that you’re describing is that it would be difficult to impossible to implement at the interpreter level, because it requires a much higher-level view of the game than the game supplies to the interpreter. The interpreter doesn’t know what a particular game “is doing” in a general, human-intelligible sense at any particular time; it’s just following one low-level instruction after another.
On that scale, your example trigger is more or less impossible to implement at the interpreter level, at least under the current structure of how interpreters and individual games relate to each other. You can’t write a macro to pick up all coins from a corpse after you kill it, because the interpreter doesn’t know about corpses, which are a high-level representation presented to the player but not something that is consistently represented at the interpreter level. Many games do not implement combat or death; and when they do, that is something that happens narratively, in the player’s mind, as opposed to being something that each game implements in the same way, so that the interpreter understands “an object of the ‘corpse’ type has appeared in the room.” Each game that implements death, combat, corpses, or coins does so in its own way; and when the interpreter executes the commands that accomplish the goal of describing these fictional objects and narrative events to the player, it doesn’t realize that “that’s what it’s doing.” It’s just comparing numbers, dumping text to the screen, parsing input, launching off to subroutines, and doing all those things that it does at its own low level. It never has a high-level view of what the game’s large- or medium-scale goal is.
What you would need to be able to do these things is some way for the player to “hook into” higher-level representations of “what’s currently going on” in the game: the game would have to tell the interpreter that a death had occurred so that the player could write a macro triggered by that event, and the interpreter would have to understand the game’s “hey, a death happened” signal and support death-related macro-writing. Ditto for every other event type that you want the player to be able to write a macro for. Currently, to the best of my knowledge, there are zero interpreters that provide that functionality in the way you are thinking about; and part of the reason for this is that there are zero games that are trying to send death-related notification signals to the interpreter, as opposed to simply telling the player about it by writing a description to the screen. It’s the same “why don’t we ‘just’ redesign the email protocols to make them secure and reduce spam?” problem: because every email client would have to support the new standard at the same time for it to work. Similarly, good luck getting over the initial adoption hurdle of getting interpreters to do extra work to implement features that no games use while simultaneously trying to get game authors to implement high-level messaging features that don’t work on any interpreter.
MUDs get around this problem by not splitting the game-playing experience between game file and 'terp, so the entire thing is a single unitary software system, written by one group of people who collaborate directly and can design the single unitary system in any way they want, including by providing precisely these hooks for whatever event types they want to provide macro support for. This is a very different thing from game-writers implementing one half of a standard (via their specific programming language) and 'terp writers implementing the other half when neither half of the standard defines facilities for macro-type scripting by the player.
I think another big chunk of this problem is that people who want to define macros in MUDs are typically people who spend enough time in a MUD that the repetitive tasks become a severe annoyance; but these are people who are interacting with the exact same software stack for many many hours, perhaps even hundreds or thousands. It makes sense to automate repetitive tasks. But even if I’m playing a largish piece of parser IF, say Anchorhead, I’m usually still looking at just a few evenings for a playthrough; and the things I’d want to automate are specific to that particular game. Part of it, too, is that parser IF game design often de-emphasizes repetitive tasks: the dungeon crawl is not unknown, but neither is it all that common, and parser IF players, as a group, really hate having to trek back and forth to move objects around or perform boring repetitive tasks. There are of course exceptions, and entire games have been built purely to troll the user on exactly this issue, but repetitive long sequences of actions are decreasingly common in parser IF.
So it’s a combination of factors: technical difficulty of implementing, plus design that de-emphasizes situations where defining these macros is likely to pay off.
Sorry to write so much! I didn’t realize when I started how much I had to say.
Don’t make me type TALK a hundred times when I can type T a hundred times. And in hard puzzle games, I bounce off a lot sooner than I used to because there’s so much typing effort involved in making the exploratory attempts.