When the listener's "berakpoint on script's start" options is unset the debugger ignores breakpoints. The debug session runs fine and if I pause it in the middle then I indeed find myself at some arbiterary point in the code and able to continue debugging, but otherwise the script will just run to the end ignoring every breakpoint I set.

What IDE do you run ?

I experience a similar problem:
Using DBG directly without listener I switched from PHP 4.2.2 / DBG 2.11.5
to PHP 4.3.2 / DBG 2.11.23 ( on WIN32).
debugbreak() and JIT breaks are still honored and a cond/uncond breakpoint request is still listed with the stack replies but no break occurs once a DBGA_CONTINUE is sent. In older versions DBGA_IGNORE stopped (IMHO erroneously) at any applicable breakpoint, now DBGA_CONTINUE runs over them. (!?)

You both are talking about different situations.
I guess that the first post concerns PHPCoder or may be PHPEdit.
I can't responce for those IDEs.
Regarding your situation, it looks like you supplied wrong file name or wrong line number. Can you list more details about what you did ?

Basically, I have a program listening and talking to 7869. Been using it for a while on different versions of PHP up to and including 4.3.0 /w DBG2.11.5

Now I tried 4.3.2 and upgraded to DBG 2.11.23. I am running a PHP script that contains a debugbreak() statement. When getting to this statement DBG spits out _one_ stack frame pointing to the line containing debugbreak() (besides some initial info). At this point I send a breakpoint request. I get back a BP frame stating module no, line no as requested. In fact it is 2 lines down from debugbreak(), no cond statements between. Now I send a CONTINUE and get back another stack frame for the debugbreak() line followed by a STEP_INTO_DONE, BREAKPOINT and a bp info frame but no stack frame (at least no current one); after sending another CONTINUE PHP runs thru until an error or end of script.

With versions of PHP up to 4.3.0 / DBG 2.11.5 upon stopping over a debugbreak() I received _two_ stack frames, one (current) for debugbreak() itself and one (level2) for the line it was written on. I sent my bp request and got back the bp info stating modno, lineno as requested. After sending CONTINUE I got back a stack frame pointing to the bp line and the bp modno.

so you see that dbg actually does not ignore breakpoints.
and you encountered problems with network protocol only.
Nobody promised that this protocol is written on stones and won't be changed.
Actually, I made some improvements and reduced number of packets passed each time the dbg stopped on BP_xxx event.
Maybe that's just the case.

BTW, breakpoint requests are changed since 2.11.5.

BTW, may I ask you what software you're developing and under what platform ?