Thanks @dave .
fading the tracks to volume 0.01 instead of 0.
That's exactly what I ended up doing as a workaround. My use case is the same as what you described from Demon Quest. I guess I would have to make sure to do it for channels as well.
Have you tried using fileplayer:setOffset() to advance to the correct position before unpausing the audio?
This technically works if I either specify a buffer size on creation (edit: or use the 0.25 second default buffer size, same thing) and add that into the setOffset() call (as this older bug report says to do), if I don't then the track audibly starts from a slightly different place (not sure if this is due to setOffset() latency). BUT, even with the buffer size factored in, when the fileplayer resumes I first hear notes from a different point in the track, until the fileplayer "catches up" and is then in sync again. If I had to guess, it may sound like it's playing what's in the buffer before it populates it again at the right offset (I may of course be completely off base here, having no other insight into the internals).
I didn't like it because of the wasted overhead of constantly decoding multiple files from disk just to have the data thrown out
I get that, and agree it's not ideal, but forcing this behavior into setVolume() feels a bit arbitrary, considering fileplayer:pause() exists separately (granted, perhaps it didn't early on), but more importantly at this point this is inconsistent with the interface for both sequences and sampleplayers, which simply get muted when the volume is set to 0. Perhaps even more importantly, if this is deliberate and was clearly documented in the API docs I would have spent less time chasing it down 
