Sounds a bit too complex and some things described may not be necessary. "delay lines, static tables, DSP struct itself" - actually, static tables would be loaded to static RAM as part of the patch. And DSP struct most likely should go to fastest memory section, because placing it on SDRAM would be the worst case scenario. Does that mean that we should only care about delay lines order in this case?
Current allocator that we use is fairly simple. It has one specific requirement to define sections in order of their memory addresses, which works well for us as this MCU has faster memories under lower addresses. So we end up allocating to faster memories first, but we have to choose allocation order accordingly.
knowledge of the board capability
The allocator itself doesn't know anything other than address and size for each section. This is probably sufficient for performing allocations starting with largest objects (which could reduce fragmentation and place more data on faster memory).
requirement needs by the given DSP
It's problematic to do it in runtime. But if we can detect at compile time which objects need updating once per block of audio rather than once per sample, we can treat them as second class and allocate them later (to slower memory).