Yep, that really is an fpc question (and I can not answer the question itself, but add some insight).
The debugger knows very little about files, units, lines in this context.
- It has asm instructions that reside at addresses.
- FPC provides to the debugger a list, for each address, what file and line it belongs too.
So for single stepping, the debugger just goes over asm statement, until that metadata changes. (simplified).
And for the IDE the debugger backend just says, look I paused, and the location is: file/line.
And the IDE shows that.
In reverse, if you set a breakpoint, the debugger searches for all addresses (start of each range) that map to the file/line. (again simplified)
So all that you observe is entirely controlled by FPC. And the debugger doesn't even know if it is caused by a macro, or an inlined include file. Or if the filename changed for some other reason.
My guess, about the opt 3 - the compiler moved the generated code around (to optimize) and in that process "lost" some pieces of the debug info.
It's the joy of writing a debugger, you depend on lots of things that you don't control.