Best practice for when to enable SoftDevice (sd_* vs. NVIC_*)

Question

The issue is that if a peripheral needs to enable interrupts (or anything else partly protected by the SoftDevice) and is configured before enabling the SoftDevice, the NVIC_* functions must be used in the initialization and the sd_* functions for disabling/de-initialization. This can quickly lead to strange code and unforeseen bugs. The same is true for using the sd_mutex* etc. 
 So what is considered "best practice" for this issue when using the SoftDevice? 
 My initial thought would be to enable the SoftDevice immediately after initializing clocks and anything else that the SoftDevice might be depend on, and always use sd_* everywhere. And wait to enable the device manager, advertising, etc. until it makes sense to do so. 
 This does make debugging a bit more problematic. But are there any other drawbacks that I am missing? Or does anyone have a better approach? 
 A define to indicate if a SoftDevice is used could be added to make drivers etc. more general, but for BLE-centered applications this define would need to be checked quite a lot of places.

Hung Bui · Accepted Answer

@ned_zeppelin: I guess you were talking about the calls to set the interrupt and priority, such as: 
 NVIC_ClearPendingIRQ(UART0_IRQn);
 NVIC_SetPriority(UART0_IRQn, irq_priority);
 NVIC_EnableIRQ(UART0_IRQn);
 
 I personally haven't seen issue when using them with softdevice enabled as long as the priority is set correctly (App high or app low). But you are right, as mentioned in the Softdevice spec: "the application program must comply with the restriction and use the NVIC API for configuration when the SoftDevice is enabled". 
 I will report this as a bug internally.