I did cover this in a bit more depth on a Wii thread the other month
Such things get tricky depending upon what is done.
The Wii quite notably saw a limited emulator compared to what the max the N64 could handle. As many N64 hacks, even those that stuck to hardware*, might have exceeded what the original emulator (or alternatives) were tasked with doing then that might make basic emulation troubled. That said N64 emulation on the 3ds is not so hot so probably not an issue.
You could port things from the N64 to the DS version and run that on the 3ds, that would however involve running the DS version which some might object to and it is not a trivial task either compared to maybe porting a hack between regions on the N64.
Also now we have seen ports thanks to the decompilation (and possibly leaked beta from the gigaleak but I think they avoided that for 3ds stuff I saw). This opens some doors and closes others, as well as makes remaking certain things a lot easier (what might take a master assembly hacker some considerable time a "I know how to press compile and took a high school class" types might well do over a weekend or even by dead reckoning in minutes.
*the N64 also saw a fairly popular use of texture replacement hacks that operate at emulator/shader level, both as "HD" textures and more conventional hacks (translation can be done as it is still a picture on the screen).
For more traditional hacks that aim to work on hardware then in general you will have assets and code to consider. Assets might be replaced in place, or someone might have repointed it to somewhere else in the ROM (expanded in size perhaps as well). Repointed stuff might well be tricky if the build tools are designed to handle certain locations, certain sizes and such like or have other assumptions. Part of the same reason it is tricky to stack patches unless one or both hack makers were aware of the other and adjusted accordingly/left space for it. If your target is the DS version then you also get to understand/find the relevant stuff in both games and adjust formats accordingly.
Code gets trickier still when porting it across as the decompiled code will not decompile the ROM or possibly even know what to make of the additional/edited code if it did (assuming you are doing more than changing a simple button read to another location it by definition was not originally** C code to be turned back into it).
**On some occasions we have seen later consoles have full high level programs compiled and injected with redirections added. Would still need either the code or someone skilled enough to parse out disassembled code though if it was run through a decompiler.
Compared to porting between regions and code revisions
https://tcrf.net/Super_Mario_64_(Nintendo_64)/Regional_and_Version_Differences , though for N64 things most will look at
https://www.zeldaspeedruns.com/oot/generalknowledge/version-differences for when differences get more interesting to explore, this gets tricky -- most code is not radically changed between regions and revisions, more what is "necessary" for their purposes. To this end you can usually still find the new locations and overwrite whatever or find similar styles of code and tweak accordingly.
