Unless I am mistaken, the rate-monotonic scheduling method has constant priorities all throughout the application? That kind of defeats the purpose of interrupt priorities, doesn't it?
With dsPIC and PIC32 target, In Multi-Tasking implementation, tasks are triggered with a fixed priority of 2.
Tasks reduces their own execution priority from 2 to 1 when they start so as to be pre-empted by any higher priority tasks. (that is a big picture).
If your UART circular buffer is implemented with a priority 5 interrupt, reception on Rx is likely to pre-empt any tasks. All drivers provided for peripheral (UART, but also SPI, I2C, CN ...) are designed to be used with a priority above model tasks.
You can trig your own tasks setting-up a Timer (Timer block), triggering your subsystem using the "interrupt" block. You can then decide the priority of your asynchrousnly triggered subsystem.
Thus, interrupt priorities have an impact.
Any application using the Multi-Tasking Scheduler can be considered real-time and deterministic unless tasks do not overload the CPU?
The scheduler is "robust" to overload, but you should never get there if you do not want to violate real-time constraints.
If you don't have overload, your system is deterministic except if you uncheck the "deterministic" option on rate transition block, when a data goes from a fast-task rate to a slower task rate. Unchecking this option allows reducing delay. (MathWorks help for that block provides further explanation)
Attached is an illustration of the multitasking scheduler obtained with the "task state" block available in the blockset which can set one various output pin of the mcu a task state.