As to your question about how this gets through testing, its simple: There's no test for CCP for 18F27Q10. There are tests for that CCP, but not for 18F27Q10. There are tests for 18F27Q10, but not against CCP.
No test for the PIC18F27Q10 CCP simulation model is the reason the simulation tool got released with a fault that would cause the simulator to crash.
That this test was not present for the PIC18F27Q10 CCP simulation model shows that the Microchip simulation tool development team has a systemic failure of process.
My issue here is not this specific, and trivial, fault in a simulation model but the fact that the Microchip development process cannot find these kinds of faults before the release candidate is committed.
This is not a situation isolated to just the simulation tool development. The pic-as(v2.20) tool chain has a trivial fault with integration into the development environment. With this fault the IDE fails to launch a debug session with the symbolic debug information included in the debug session.
I point this out here to show how low the quality bar has become for Microchip software tools.