For more half-baked ideas, see the ideas tag.
Why’s it not possible to run a deeply nested set of programs (eg. a large build) and have strace or gdb just trigger on a particular program? For example you could do a regular expression match on a command line:
exectrace --run=strace --cmd="\./prog.*-l" -- make check
would (given this theoretical exectrace tool) trigger strace when any child process of the make check matches the regexp \./prog.*-l.
Or perhaps you could trigger on current directory:
exectrace --run=strace --cwd=tests -- make check
I guess this could be implemented using PTRACE_O_TRACEEXEC, and it should have less overhead then doing a full recursive strace, and less annoyance than trying to trace a child in gdb (which AFAIK is next to impossible).
Richard WM Jones 
I receive your blog post as email subscriptions. I view the text only versions. For some reason, these posts come in with ultra long lines of text. I guess the standard email line wrapping isn’t working. I’d recommend reporting this as a bug, because it’s not easy to read these posts.
https://people.gnome.org/~walters/gdbifmatch.c
Yes, that is very interesting, thanks. Did you think about using ptrace to implement it? I’ve found LD_PRELOAD to be troublesome, the obvious problem being it doesn’t work for statically linked programs and certain other programs that play with environment variables and/or dlopen. (Speaking from experience when we used to use fakeroot/fakechroot).
You can debug multiple processes with gdb:
http://tromey.com/blog/?p=734
It still has some rough edges IMO. But I’ve debugged things like test failures deep in the gdb test suite this way.
For the scenario of “I want to debug process X that hasn’t started yet”, I think the current plan is still global breakpoints:
http://lwn.net/Articles/469769/
There’s a gdb patch but it hasn’t gone in yet. Nor has the kernel patch, AFAIK.