As far as I can understand from ctc datasheet RETI detector is only usefull when priority management between several separated devices in needed (cascaded priorities). More over this mechanism shouldn't prevent CTC to latch its own interrupt even when any other interrupt is currently in service.
This was my first thought also.
But at the end, the datasheet is clear:
If a device or channel is being serviced in an with an interrupt routine, it cannot be interrupted by a device or channel until service is complete.
That's why Journey is a good test case (otherwise a stupid game): it enables interrupts in the int3 handler, and it doesn't expect that int3 will happen during that (until RETI). Otherwise it will crash. So that's why the in-service bits are needed. I've cross-checked this in MAME debugger, too.
One question remains : does CTC allow for nested interrupt ? That is when a new interrupt occurs during service routine of previous one, should int_n be inserted before end of service routine (reti) or immediately after ?
Currently the lower or equal priorty interrupt is lost. Maybe it should be executed after the higher or same priority is serviced, need to test (the 68009 MFP stores pending interrupts for example). At least in Journey, the CTC behaves correctly. Maybe debugging Power Drive will give the answer.
Upd: Power Drive works also. The monoboard connects VBLANK to CTC input trigger 2, this way it doesn't has to use it as a timer. This should trigger once/half frame (60Hz).