I know your position on this (it is even in the code), but I thought I would point out a couple of points that may influence you.
Firstly, it would appear that no-one with the exception of swissembeded has used the DSP features of any PIC! and he seems to have come and gone.
Secondly, while on the surface it appears that the dsPIC24/30’s allow the saving/restoring of the DO registers, in reality there is a limit of 7 levels (read-only 3-bit nest register) and in practice they are limited to 2 levels (hardware stack) as Microchip’s dsp library makes no accomodation for a software stack. Worse the DSP accumulator status flags (overflow and saturate) are read only and not restorable (except for testing and executing code to set the flags). To be fair I could not find any code in the libraries which used those flags.
All of which to say that, practically, on the dsPIC24/30’s one is restricted to 1 process and on the dsPIC33E’s 2 processes using the DSP engine.
Of course you are asking yourself, if no-one is using the dsp then why bother?
Given the PIC’s many, many varieties it can be a peripheral choice. In particular the dsPIC33EPxxxGP/MC50X has a CAN peripheral while the PIC24EPxxx’s do not. The EP series is interesting because it has the largest flash size available (512Mb) as well as a decent amount of RAM (48Kb)
Finally, as you may remember there is a port on the FreeRTOS interactive site for the dsPIC33Es which I don’t mind maintaining (albeit slowly and not during the summer - can’t waste the short sailing season)