Lambda the Ultimate

Other than lisp and scheme (whose syntax-case macros are entirely different from lisp style macros), there are a number of languages that provide the same kind of facilities. You many want to look at these at least.

TCL
- it uses upvar and upeval to get the same effect as macros. (upvar and upeval executes in the named frame (usually the parent function))

FORTH
- create does>

Perl6
- macros which lets you operate on unparsed input or AST

This thread has quite a bit of information on macro systems.

One recurring theme I've seen in the discussions around here is that all things come back to Lisp. Specifically Lisp macros.

Really? The vast majority of conversations don't even mention Lisp macros. Most that do are ones along the lines of this one. In a previous comment I reference other previous comments about the actual capabilities of macros. For you the capsule review is this: the expressive power of Lisp does not come from macros.

Your particular scheme is worse than most.
1) There is almost no benefit to your scheme versus using an external tool. The particular case you give could easily be replaced with a usage of sed.
2) You don't want to operate on strings. You want to get to a structured representation as quickly as possible and you want most processing to be over that structured representation. Of course, you can't entirely avoid processing strings if you want to support a different lexical syntax. Common Lisp reader macros, the proposed QuasiQuoting extensions to Template Haskell, Forth parsing words, and/or Camlp4 are things to look at in this regard.
3) In line with 2, your approach to macros composes very poorly. You also seem to completely lack an ability to modularize or localize them.
4) Also extending 2, you can't "simply search for the pattern." Recognizing the pattern will require parsing in the typical case and further should only be applied in certain contexts (and recognizing those contexts requires parsing.) In line with 3, since the "macros" have no way of knowing about each others existence or what the others do they will conflict with each other.
5) To really get something out of language integrated macros you want the implementation to provide hard-to-get or implementation-specific information. Things like the active lexical enviroment, the type environment, representation information, the results of any compile-time analyses. You'll want to be able to query details such as what methods are in a class given a class name, what class a method invocation is part of, etc. Ideally, you want to expose all the information the compiler has.

Basically, as it currently appears, using your "macro" scheme to do almost anything at all would be non-trivial and/or error-prone and create fragile, hard to understand code. It would have no benefit over writing an external tool (in 2e if you like) that processes the code.

Therefore it is claimed that one can create other mini-languages within Lisp. However, the calling of a Lisp macro is still in the form of a function call syntax. So even if other languages implemented Lisp-type macros, this still doesn't solve the need for domain-specific pre-processors such as Oracle's ProC (for using embedded SQL in a C program), or the QT MOC preprocessor used on C++ code.

Check out this approach: http://www.meta-alternative.net/calc.pdf

It demonstrates how to embed a language with another syntax into S-expressions based language (i.e., Lisp), using macros and regular parsing features.

MBase itself contains a number of embedded languages implemented in a similar way, which includes a language for defining ASTs (N.B. - symbols there can contain complex syntax), a pattern matching language (again, symbols are decomposed as they contain syntax), and some more interesting things.

And, of course, you can replace your parser completely. To some extend you can do this in Common Lisp with reader macros, or you can implement your own "S-expressions+Something" parser and read your program through it. Lisp macros are absolutely flexible, there's nothing you can't do within this approach.

...roughly like Perl5 source filters? (See Filter::Simple and Filter::Util::Call.)

Don't forget to expose a way of dumping the generated, final, code.

...as a language author?

Now my question is if this seems like the ultimate macro system? Or is there any problems with it that I'm not seeing?

Example:
/* Since the 2e language doesn't have a native "if" statement... */
/%
regex_replace(input_code_string, "if {\(.*\)} then {\(.*\)} else {\(.*\)}", "ifelse(@(\1), @(\2), @(\3))"
%/

"Ultimate" depends on your goals. Personally, I can't read what you wrote there. I don't need something that complex. Humble yourself by reading the original source code for the Bourne shell. :) My biggest concern is that I can't infer the complexity of the macro operator. Operator complexity is not just an implementation detail, but a client-facing design decision. How easy is it to do generic programming in your macro system?

As a logician, you probably don't need a practical example and your crazy one will suffice. As a designer, you'll want to reconsider your pursuit. Design is not simply subtracting away the weaknesses you see in one system in order to make a better system. This applies to all kinds of design, not simply languages. See for example Design Paradigms by Henry Petroski, which covers the challenge in civil engineering projects. A language design-related example of this is C# operator overloading vs. C++ operator overloading. In C++, they can be implemented as via a static method, instance method or virtual method. In C#, it is only a static method, which accounts for your practical scenarios. In fact, you'll find that its features these languages both lack (multi-methods) which force kludge solutions to otherwise straight-forward problems (Meyer spends 26 pages of Effective C++ explaining how to properly simulate double dispatch in C++, and doesn't even get to Line Item 51: How not to hang yourself writing c++ to do multi-methods).

To add to what Elkins said:

I view staging as a generalization of macro operators. The fundamentally hard challenge in macro system design, as I understand it from reading Walid Taha's papers on multi-stage programming, is a static typing system where the DSL knows nothing about its parent environment. In other words, you have to deliberately "grow the language" and cannot mix ad-hoc DSL code with general purpose code. As I see it, such design challenge is similar to the partial classes versus aspect-weaving argument. Partial classes advocates argue that the library author should determine what hooks can be defined. Aspect-weaving advocates think existing code should be re-editable, including third party libraries.

also, taken from http://lang2e.sourceforge.net/:

The design of the 2e language had several goals. One of those goals was to see how useful it would be to have an iterative form of the C inline conditional.

This sounds like Icon, a language largely created with the intention of demonstrating the power of generators. Its predecessor, SNOBOL4, was actually used for code snippets in Vol. 1, Theory of Parsing by Aho and Ullman (pre-quel to Dragon book). If so, then you may want to prototype your language in Common Lisp using cl-cont.