Z3RO21,
arborint, yes, there are many security concerns which arise for bad design decisions, like dynamic includes. Other examples would be dangerous eval-like functions, register globals-like behaviour (extract, parse_str, variable variables) etc. Also administrative interfaces not protected by authorisation checks, file uploads etc.
My example was with mysql, but I didn't mean escape = mysql_real_escape_string (in fact mysql_real_escape_string may not be enough security for certain SQL cases). Escaping is also cleaning data before outputting it to HTML or XML as not to contain HTML and XML syntax. It is escaping characters when dynamicly creating regexps. It is escaping arguments before calling exec-like functions. Every such function has its own method for protecting syntactic characters from interfering with it (no, not addslashes

), which I generalise as "escaping"
As I said maybe it's a matter of what we call "escaping". The last few weeks I am thinking of how dangerous situations arise in usual programming, and I'm more and more coming to the conclusion that the paradigm we are using when imagining syntactic-level security threats is somewhat flawed. Also the APIs that allow the said syntactic insertions seem flawed. It is a bold claim, I know. I will try to construct an elaborate example these days to scientifically check my theory
Another thing I should state is that I am in no way advocating that data should not be validated. On the contrary, I personally am almost anal about validating (and type-converting) all data in my code. In my view though, I don't do it from a security necessity, but for keeping data and logical integrity in my apps. I agree that it adds a layer in security and I vote with two hands and a leg about doing it. (So,
Z3RO21, we may actually be in agreement after all)