This is a recurrent problem that I noticed in a few projects and I got to thinking about it and a resolution.
Projects sometimes use caching and maybe sometimes a form of subtle patching (especially to class definitions names) for class definition files.
But then, in order to enable Xdebug to work on the original source files, they use some form of stream-wrapping (either namespace://path-to-file with stream_register_wrapper, or php://filter=someFilter/resource=... with stream_filter_register). Both methods get passed paths to the original source file but return the content of the cached/patched file.
While this does work for Xdebug, it breaks other things (such as the opcache) and it's fixing a problem where it's not.
The problem to solve is "how can I tell the debugger that the code in <cached_file> is the same (line numbers at least) with <source_file> and when debugging, I will actually be debugging <source_file>". Formally, this would be best resolved at GUI-level of course, but that's not likely to happen.
So I was thinking if it would be difficult or a bad idea to devise some form of mapping in Xdebug to map the cache files to the source files.

To make it clear formally, it would be a two-way hash in the form of:
<source-path> <-> <cached-path>
Where Xdebug will follow these 2 rules:
1) Breakpoints on <source-path> also apply to <cached-path>
2) During debug, <cached-path> steps (code points) should be reported as <source-path> back to the GUI