Yeah I dont use interrupts unless I have to, or unless I want to do a simple demonstration as they are a bigger trap than just booting a processor. One little mistake and pain. Uart interrupts are generally tricky, depends on the uart (talking general not necessarily pi) Usually you get an interrupt when a buffer becomes free on the TX side or hits a low water limit or not empty or a high water limit. timers and system call interrupts and such are easier to demonstrate the mechanism of telling the peripheral to interrupt, then enabling the various layers between the interrupt and processor, place the vector/handler clean up and return. I use the uart for debugging primarily and/or it is the forground task, so I rarely if ever use the interrupt for it.
My belief is the first steps are where we lose a lot of baremetal programmers no matter what platform. mastering the tools enough to build a binary that works, enough of a bootstrap to get running, and then some peripheral management to see that it really did boot. I have personal curiosities like aarch64 and how to "split the cores" and actually the added pain to get an interrupt/system call through on the 64 bit arm. So I went down those paths. With help from the other folks here. Pay it forward.
Certainly if you have multiple interrupts then it gets into interrupt priorities if that is part of the design. single or multiple there is the how do you clean up, what if one happened while I was blind, from the time it asserted and the logic took over to when I could possibly safely switch modes or re-arm the interrupt, etc. Do I want to do it that way or check at the end of the handler to see if another came in, so I can control when the handler gets interrupted. Then timer plus uart, plus other, what if anything overlaps what if anything is completely separate. All part of the fun.
Enjoy, you have found a great resource here, I have not seen a forum this useful in a long while.