I can see what you're trying to do but the method and the syntax you're suggesting is confusing and unnecessary.
Firstly, lacking a '/return' command doesn't really make much sense. It limits the macro to being a single statement and, from your examples, it seems like you want it to simply regurgitate existing identifiers using new names.
In fact the only one of your examples that couldn't be done right now using a regular alias with the /return command are the ones using $n parameters. Personally I'd rather see an identifier to access identifiers/variables from a scope outside the existing alias. This would enable you to do what you want and be a lot more dynamic since it would allow anything that used it to also accept parameters itself.
Your method does't seem very practical for signals anyway. The ability for scripters to write signals that provide identifiers in signal events is all well and good (I've suggested this before), but if the scripter writing the signal event has to call an alias to generate them doesn't that defeat the object somewhat? Surely it makes sense for the identifiers to be supplied when the /signal command is used.
