The effect of performing an LDR or LDM with R15 as a destination has always been well specified in cases where the least significant bit of R15 wouldn't be affected. None of the instructions following the LDR or LDM will in any way affect program execution except in the case where the loaded value matched their address, or in the case where the LDR or LDM had a conditional skip modifier causing the instruction to be skipped.
On the ARM7-TDMI, the execution time of every instruction which has R15 as the destination, or (for LDM) one of the destinations, is specified as taking two cycles longer than the corresponding instruction would take with any other destination. This is most likely a natural consequence of the ARM7-TDMI needing to perform at least two cycles worth of preparatory work before executing each instruction, and needing to abandon any such work that had been performed on the two instruction words following the instruction modifying A15, but I don't think the "official" data specifies the internal workings in such detail.
An interesting feature of the ARM-TDMI, by the way, is that any bus failure that might occur while fetching an instruction will not have any effect unless or until all previous instructions have finished execution. If e.g. attempts to access memory address 0x00008000 and 0x00008004 would trigger bus faults, and address 0x00007FFC holds instruction LDR R15,[R0], then the bus interface would report a fault on the cycle before that instruction would be executed, and another fault while that instruction was being executed, but the act of writing to R15 would prevent those pending fault conditions from affecting program behavior.
Notet that if an attempt were made to execute code from a region of space where reads could trigger side effects, the core would have no way of reverting those effects if the fetched instructions were abandoned. If memory serves, the intention was that the core would tell the bus interface which accesses were code fetches and which were loads, and that the bus interface would respond to any attempt to fetch code from an I/O address by reporting a bus fault back to the core but otherwise ignoring the attempt. If the fetch had been performed speculatively for an instruction that never ended up being executed, it would have no effect, and if an attempt were made to execute the instruction it would trigger a bus fault since any such attempts would almost certainly be accidental and erroneous.
