I think what you'll end up needing to do is write a full parser, or even parser generator (plus the grammar to feed it), to implement your language. Throwing regular expressions at the task would seem difficult - at best.
Even C's macro preprocessor is a more complex exercise than regular expressions can allow for - and what you describe looks like it would be more complex than #defined macros.
preg_replace_callback could be used, I suppose, to shift some of the complexity out of the regexp and into code. That code would almost certainly involve further calls to preg_replace_callback, and for any language that aspires to general use there'll be bound to be some recursion involved among all these callbacks/regexps. If you write the parser by hand you'll need to pin down exactly how the language will work in advance, because it would not be fun to modify the parser later.
The parser generator approach would require more work up-front; not the least part of which is the fact you'd have to design the language in which the grammar is written and write a parser for that. But once you do have a program that, given a grammar, will write a program that will parse a program written in the (scripting) language specified by that grammar, it would be much easier to experiment with the scripting language because you wouldn't have to keep rewriting the parser from scratch each time.
Or you could use a pre-existing parser generator; the name that comes to my mind at this point is Lemon. Hang on a tick... yes, there is a PHP parser generator in PEAR based on it, but ... no ... that's not the one I'm thinking of ... Ah, it's called Lime. Over at Sourceforge.
So given that, and once you're able to describe your language well enough to explain it to a machine, you'll have what you're after.