When the scheduler is not running, vTaskEnterCritical() sets the system priority to 4.
But vTaskExitCritical() does not restore the priority to the previous state when the scheduler is off. So if these functions are called with the scheduler off,  you end up with a different priority and possibly many missing hairs from your head!!!    Since the uChip USB functions set the ISR IPL to 4 (in code, not just the ISR header) this effectively disables the USB interrupt.

This is a deliberate ploy for all the ports, not just PIC32. Once you start calling FreeRTOS functions interrupts are left disabled to ensure an interrupt that tries a context switch cannot happen. Interrupts are reenabled automatically when the scheduler starts.

This confuses me a bit.  Isnt the whole idea of the EnterCritical()/ExitCritical functions to provide control when a context switch can occur?   If the scheduler has not started yet, what type of context switch would be harmful?  To leave the CPU in a different state when finishing the call set seems wrong IMO.  I modified the ExitCritical function to restore the priority because I have some things that must run before and during the scheduler running.   Are you suggesting that this is unsafe?

It is only unsafe if: 1) You install and enable an interrupt.
2) The interrupt handling function executes and uses a FreeRTOS API function that modifies the state of the FreeRTOS kernel (which has not yet been initialized) or attempts a context switch (when the kernel has not been initialized).