If the 'block of interrupts' to be enabled at the NVIC level is 'changeable', then Mark's addition of 'saving the incoming state' is a cool addition (for a few more instructions), but note of course that M0+ only has ONE set of 32 interrupts, so there is only one 'wordful' to read or write at any time. Personally, however, I would want to keep the 'enable/disable process overhead' to a minimum and use macros rather than the cost of a full procedure:
extern uint32_t Port_IntsDisableCount; // count of performed disables
extern uint32_t SavedNVICints;
#define DISABLE_PORT_INT() { Port_IntsDisableCount++;\
SavedNVICints = NVICICER;\
NVICICER = (1<<(INT_PORTC-16)) | (1<<(INT_UART0_RX_TX - 16));} //disable these
#define ENABLE_PORT_INT() if(--Port_IntsDisableCount==0) \
NVICISER = SavedNVICints ; //If we get back to 'base level', enable all interrupts we had before
Bringing in SysTick adds a new wrinkle. This is another case where M0+ is 'less clean' than M4, since we can set SCB_SHPR3_PRI_15 to match our lower 'maskable interrupt' group, and thus BASEPRI in M4 will affect it as well. But that does beg the question --- can you just 'work' with this lowered SysTick priority, and simply structure your code so that the SysTick handler interrupt is safe?
I fear that clearing 'TICKINT' does an 'actual' DISABLE, which means, like disabling any interrupt 'at the source' opens a window whereby the event will get 'missed entirely'. The ICSR register mentions 'SysTick Pending', but I see no indication of how that might work. I suppose you could also DISABLE and ENABLE the SyTick-counter operation at the same time as the TICKINT bit, BUT what consequence either possibility (rollover loss or count-clock-delay) has on your 'timekeeping' functions is 'up to you'. Personally, I would eschew SYSTICK in this environment in favor of either RTC or FTM timekeeping, so that you can stick with NVIC-processed interrupts to get the proper 'pending' hardware to implement 'hold' on exceptions, and with that you can GUARANTEE a max interrupt-response-time for your 'critical' function to be the 'best hardware can do' (longest uninterruptable instruction, stacking process, plus.... which ARM lists at 15 clocks for zero-wait-state stack-RAM in M0+, 12 clocks in M4)