In this case, UNISOUND doesn't provide results more meaningful than using ORPHINIT (though you can test using UNISOUND's /xofi option, if you insist). Only CWDINIT might give you a few more clues. While I don't think it is a matter of initialisation software, you may want to try that, just to make sure that you see the same results as my testing indicated.
There is one more point worth discussing: all Crystal parts (starting with the CS4235, I think) implement automatic mode switching. This can present a few problems; in particular, if you are implementing a TSR that may periodically access Sound Blaster-mode registers. Unpleasant things have been known to happen if you access anything in Sound Blaster I/O space while a WSS-mode operation is in progress, especially DMA-mode PCM playback or recording. If you're only "trapping" port accesses and allowing/restricting access to the actual hardware when software actually performs such accesses, you shouldn't have too many problems, but if you are using a timer or some other event to trigger a read/write of register values, be very careful, as the results can be very unpleasant, especially if wearing headphones.
I suspect that similar issues are possible with YMF71x-based designs, among others, so thorough testing is clearly warranted.