Embedded system task scheduling for data aquisition on a CAN network
Yes, it seems logical to me.  Although, what's the maximum amount of time that the lidar peripheral could be busy?  If that is more than 1 millisecond then you could miss a transmit opportunity.  Maybe the busy case should just skip over the data read rather than looping back to poll the status.

Yes, the lower priority interrupt handler will be held off while the higher priority interrupt handler runs.  If the higher priority timer interrupt handler runs longer than it takes for the CAN peripheral to receive enough messages to overflow then you would lose messages.  That's why it's a good rule of thumb to keep interrupt handlers short.  And if all your timer interrupt does is set a flag then I doubt whether you're going to have a problem.
Another way to consider this is what is the penalty when either interrupt handler is delayed by the other.  When the CAN interrupt is delayed by the timer interrupt then you would add lag to CAN response or worst case drop a message.  When the timer interrupt is delayed by the CAN interrupt then you would add jitter to the timer interrupt.  Worst case would be dropping a millisecond but the CAN interrupt would have to run for more than a millisecond for that to happen.  So what is less desirable for your application, a little lag or a little jitter?

It's doubtful that either interrupt would break I2C communications.  You're probably using an I2C controller peripheral that transmits/receives bits mostly independently from the CPU.  The I2C controller will continue to clock in and out bits as necessary without affect from the interrupts.  (If you were bit-banging each bit then there would be more of an impact because individual clocks could get stretched out by an unrelated interrupt.  But even that is not necessarily a problem because of the synchronous nature of I2C.  The slave device shouldn't care if the I2C clock pulses get stretched out.)

It may be acceptable to poll the lidar status.  If you don't have anything else for the CPU to do then what's the harm?  But if the lidar peripheral has a &quot;data ready&quot; interrupt of some sort then you could enable that interrupt and wait for the interrupt rather then poll for status.