nesdev.org

If I was designing an NSF format based on NES files, I'd just make it put an initial value into register A to select the song, and otherwise act exactly like a regular NES emulator.
Obviously emulate the PPU's NMI. Maybe emulate the rest of the PPU as well just for the sprite 0 hit, but that's probably overkill, and would waste a bunch of CPU time.
Use whatever mappers exist. Might lead to mapper hell though.
No built-in custom playback speed, use one of the cycle counting mappers (like FME7, or VRC) if you want that.
And if you need to save on CPU usage for some reason, you can always use PocketNES style speedhacks to detect an idle CPU state.

If I was designing an NSF format based on NES files, I'd just make it put an initial value into register A to select the song, and otherwise act exactly like a regular NES emulator.

One goal was for these ROMs to be able to support use on a NES or normal NES emulator, if they wanted to.

And if you need to save on [host] CPU usage for some reason, you can always use PocketNES style speedhacks to detect an idle CPU state.

I hadn't thought about the host CPU issue, which is relevant. Would be simplest if it for example only optimized the case of an infinite jump loop.