I'm not familiar with those others. I used PCEAS to write some NES code.

 What I did:
 
 included the rom (minus the header) as a binary with .incbin "some.rom"
 after the include, I used .bank and .org directives to overwrite the code with my code and/or data
 assembled into a headless rom, then reattach the original NES header.

 Presto.

Mapper details should be unimportant.  Banks are arranged the same way in the ROM regardless of the mapper used:  offset = bank_number * bank_size + 0x10;

Nearly all mappers operate on a single bank size, so if you make that an assembler directive or something, you can use the bank number and CPU address to find the ROM offset:


Output ROM offset is:   ( 0xB753 & ((8<<10)-1) ) + 0x0A * (8<<10) + 0x10 = 0x15763

If you want to get fancy you can allow for a configurable header size (instead of a fixed 0x10 byte header) to allow for possible trainers, or for NSFs which have a 0x80 byte header.

All mappers I've seen have either 8, 16, or 32K bank sizes... so nothing really unexpected to bite you in the arse.  NSFs are 4K, so you'd have to go at least that low if you want to support those (but NSF support would introduce a whole new set of problems, since the start of the NSF file doesn't necessarily land clean on a bank boundary -- so you'd have to examine the header to properly get file offsets.  So it probably isn't worth it).

A setup like this would work for any game regardless of the mapper used.  No need to wrap your head around any one of 200+ mappers.

Some complications could arise for some mappers which use multiple bank sizes (VRC6:  024 comes to mind), but the end user can deal with that on their own... as long as you allow the .nesbanksize directive to be changed midway through an asm file.  And even if you don't -- the logic could still be worked out -- it'd just be a minor annoyance.

All and all... it shouldn't be that difficult, IMO.