Two main scenarios.
1) The two different patches presumably both work on the binary but their respective rebuilds are not compatible with each other
2) The two different binary patches conflict in some manner.
2) is unlikely here; AP tends to be a matter of disabling it by overwriting the checks/forcing them to come back good which is typically done in place for the DS*, adding functionality to use the Dpad will tend to involve adding things. 2) happens more when you have two things trying to add extra functionality and using the same extra space for their expanded code, or two things handling the same concept (say text handling for the more common scenario) and thus conflicting.
*as far as I know there are no challenges like the Banjo Tooie thing for the N64. That is getting off topic though.
Best bet here is do the ap patch. Rip it apart with ndstool and grab the changed files (presumably arm9.bin and maybe some overlays but check -- any number of file compare tools will do, and if not then zip them all up and compare CRC32 values in their respective windows)
Do the dpad patch on a clean ROM. Rip it apart with ndstool (or equivalent) and have a look to see what changed (probably the ARM9 again but maybe the ARM7 as well).
If it is just the ARM9.bin files that are changed you will need a way to merge both changes. I don't know if compression will get involved here, if it is then decompress as well (crystaltile2 lies a lot about detecting compression, Cue's DS compressors should handle things here --
https://www.romhacking.net/utilities/826/ ) and recompress after the fact. Remember DS binaries use BLZ format rather than the more common DS BIOS formats (aka type 10 or type 11 LZ) but again Cue's tools have you covered.
Here I would then make an IPS (you want a nice dumb format, not something that tries to be smart like xdelta unless you want to force it to ignore source verification/checking) to patch the original (but decompressed if necessary) ARM9 into the decompressed AP patched ARM9.
Take this IPS and apply it to the (decompressed if necessary) ARM9.bin of the dpad patched ROM. As the AP patching and dpad patching should not interact for this then all is good. Recompress if necessary. Repeat for any overlays that also changed for the AP patch.
Finally rebuild the dpad patched ROM with this combined ARM9.bin file. Hopefully that should get you what you want. Personally I would suggest just getting a flash cart but if you want to use the compatibility layers then play it how you will.
Option 2. Apparently Spirit Tracks was released prior to my copy of the Wood RPG source code being bundled so the patches for it are still in there. If push comes to shove we can figure out where the patches need to be and insert them manually on top of the dpad stuff.
If memory serves the way wood RPG did its patches was essentially use the cheat functionality to patch the binary in memory. I am guessing those are the addresses and payloads. You will need a decompressed binary, and to be aware of where it lands in memory (ndsts will tell you that
http://www.no-intro.org/tools.htm ) to make sure it lands where it needs to land. If those are the whole AP patch thing for this game (possible -- 2009 was still fairly sane for AP) then even better.