It sounds like you want to add save support to an emulator that runs IPF and/or CTR and/or stream files
As you say it's not an issue on Amiga - in WinUAE (Toni might correct me on this), there is a "diff" file, and whenever track data needs to be accessed the diff is checked first. If it's valid for a track the data stored there replaces the data from the IPF (or CTR...) etc files.
Notice, that while all IPF/CTR/stream may (and often does) contain variable density data, or data with higher/lower bitcell density than normal this is not an issue when rewriting the track data, simply because the emulated machine is not capable of writing such data at all without hardware modifications (that was the reason to use these densities in the first place).
The problem is slightly more complex when a program only partially writes a track though...
What you may consider to implement is how Atari ST emulators deal with saving to IPF/CTR.
I think the idea is very similar, just replacing the data works at the sector level.
At least Nicolas (Hatari author) is on this forum, but both Hatari and Steem are open-source, so you can find out what they specifically do.
Again, what is worth keeping in mind is that the FDC can only write sectors using the standard cell density (without extra hardware added, like afair the Discovery cartridge), which simplifies the problem.
In both cases it is an issue if the track is partially written; on the Amiga it happens when not an entire track is overwritten (which is not common), on a generic FM/MFM controller that's almost always the case (except for write track command).
You can switch between the bitstream (or the lower-level flux reversal) representation vs decoded sector data depending on which sector is "dirty", or keep the original track data as a single revolution only as soon as it gets written to.
That is possible with IPF as the whole track is guaranteed to be good (otherwise the IPF wouldn't exist), so you would not need multiple-revolutions to ensure that at least one those contains correct sector data.
It is not trivial to do this for CTR or stream though; finding matching data on multiple revolutions is a very complex problem due to variation in the data and way too many other factors - so not worth it for saving data in an emulator.
An additional complexity arises if the cell density is not standard on the track/sector overwritten. Depeding on the cell width used on the original recording, the newly written data may overwrite more than one sector, additional gap, or actually occupy less space than a sector with the original density on the same track.
In either case the new sector data gets fully written, but what remains of the data following (or inside) the existing sector can be very different.
I do not think that any emulator deals with this edge case though, because if they do, that means that they support overwriting copy-protected data on an original disk - but I am sure Toni or Nicolas would correct me if the current emulators actually do support this edge case as well