Coming off easy street.
On the GBA - everything is mapped to memory with no banks in any dumped commercial ROM (flash carts, some homebrew, lucky lucky man/tourist trap 32 in 1 pirate carts and the undumped version of the whole shrek film being an exception). It is mapped to 3 locations and as an added bonus most games do not use the upper 16 megs so you almost always (mother 3 is about the only exception for a finished ROM hack) have a free 16 megs.
On the DS - assuming your file format will hold it then just press rebuild ROM with the new ROM in it assuming you are not going to go over 512 megs (most games sit at around 64 to 128) and the ARM9 binary does not go over 4 megs (less anything for the overlays). I have pondered using the GBA section as extra memory for various things (who does not want another 32 megs of fast bus mapped memory) and certain hacks (as in actual get code to run on a locked system hacks) used it but I have not done anything like using it as memory yet.
Other systems- can get tricky if you have banks to deal with as things can get quite in depth depending upon how the banks work on your given game/system. Of course a lack of banks, or mappers depending upon how you want to view it, can be just as troublesome if you need more space as the mapper/bankless games are often packed to the limit.
The two methods seem to be
Fixed window and last three quarters shifting to whatever.
Complete page swap or alignment change. Whether this is backed by having the binary or a fragment in memory goes game by game and others can choose to do things like copy the game to all banks/discs (Final Fantasy 7 being a fairly notable example here).
How banks are swapped (register in standard bus, register on cart, soft memory lookup should you construct an appropriate address) is what you will have to figure into your routines if you play this game. Switching latency I imagine would be one of the more annoying issues though adding a function to a game that hooks at random intervals and having to do a selected bank check I imagine to be just as fun.
How to tell if it is free.
Runs of 00 and FF (or occasionally alternating 00 and FF), especially at the end of a ROM or at the end of a section, are a good bet. I already mentioned the niceness of the GBA and DS but for some banked games you might have an unused bank for the mapper/cart type or have a remarkably similar mapper you can convert to (the GB/GBC being quite good for this on some occasions).
You can try using tracing, pointers and other such methods and they are well worth it but in practice it can be hard to account for all the edge cases (especially for games with minigames, post game content and other "rare use" sections). Same applies to the RAM though you can do things like DEADBEEF padding (floodfill the RAM with DEADBEEF and any DEADBEEF left at the point you care about, assuming the game did not otherwise initialise the memory, is hopefully good to go) and you may run into pointers (as in the cheat maker's nemesis and favourite of those giving tests on C programming) on later consoles more often which is fun.
The DS usually piles endless junk into the binary (error messages in every language or something) which ends up in RAM so I am happy enough there (though I will still tend to avoid repointing if I can). You can also optimise games or do things like remove compression if it bounces something into work ram on the way to VRAM. Truth be told most of my work is not new variables as much as altering existing ones or subverting functions to give them more scope which is more trouble finding space in the binary (which, as covered, is usually not the hardest) in which case I need temporary variables at best and can often cover it with registers or the stack.
Failing. I was once trying to help out with a DS phoenix wright game and I missed that the VRAM was filled up by the increased sprite size (it was a multi layer affair and so quite easy to do), cue head scratching as I tried to pin down what went despite the file "decoding" properly. Sprite and VRAM stuff is quite common in other areas where before it might have used repeated tiles and you only had say two kanji before with a blank tile in the middle.
In my "breaking formats" phase I saw things that, were I doing an actual hack, I would have run foul of a few apparent limits which were far lower than the pointers they could use would theoretically allow (full 32 bits but not going much past 24). That said I have come the other way and used formats with 32 bit pointers to trick jump commands and whatever else to read way later than was originally intended. I once played around with a game that was almost all scripting engine down to commands themselves carrying their length as well as assets they could load but later ran up against internal memory limits. I believe one of the fire emblem DS hacks ran into this as well but was rather odd (something about the characters per line being increased but running out of memory somewhere else if memory serves).
More commonly it is just the same as when you corrupt or screw up inserting a game and you crashes, corruption, oddities and more depending upon what you have done and how good the games are (and defensive coding is hardly a single player/local multiplayer* game developer speciality, especially upon old consoles and handhelds).
*I say local but the multiplayer lot are not on my shortlist of potential hires should I be developing something that has to be seriously fault tolerant (medical and industrial stuff for instance). That said I would probably struggle to convince myself to hire any game programmer that did not cut their teeth on anything playstation or older.
Common for such blank sections. RAM can vary though I am not surprised either way. With consoles traditionally not be OS laden, multitasking systems with mountains of dedicated VRAM it is certainly not a sure thing though like it might be on a PC.
In a ROM... given we dump ROMs to the power of 2 sizes (give or take banks) then yes. Given we often fish extraneous data from ROMs then yes again. Moreover given we tend to alter games rather than expand them you can reclaim space.
3. My first thought is to say halting problem and leave it at that. I have seen things scan known ROMs to determine what goes (Atrius' GBA golden sun stuff being the most notable though some of the pokemon lot do OK too), compression searching is a thing, you can do things like log BIOS and ROM calls and on the DS and other filesystem using systems header parsing and other mild heuristics can happen.
Even without the halting problem most of ROM hacking is concerned with divining the weird and wonderful that programmers ended up using for formats so that is troubled again.
I am waffling so I am out for the time being.