Temporal Flux is not open source, right?
The main program is not currently open source, no.
I'd be interested to get some insight on your approach to managing how data gets saved back into the rom.
This is quite a lengthy topic, as it took me two years to get beyond the most basic saving, five years to get everything compartmentalized, and eight years to bring me to my current project-oriented design. Do you have a more specific interest? There is a lot of detail I could get into, I'll start with some very broad strokes here about how the data is treated.
First, its important to note that loading data and saving it are equal endpoints traveling in opposite directions. Thinking of them as unrelated or wholly separate processes will not produce good code. To this end, Temporal Flux employs record based loading and saving (as detailed in the Temporal Flux Plugin Architecture). Each record contains all of the information needed to load the data and save it back, including extra pointers, custom data parsing, and more.
Each record may also have upto three states, though anything more than one is usually abstracted by the form that displays it, not something stored in permanent memory.
The most primitive state is identical to the way the record appears in the original ROM data. Most of the 2000+ individual records Flux extracts only exist in this form as the data is simply not complex; there is no further need to parse the information. More complex records only exist in this state briefly after being loaded or before being saved. Examples of records in this state include Location Properties or Song Instruments.
The middle state is pre-parsed. The data is complex, almost always not of a fixed length. This makes it difficult to determine where a specific datum of interest is or should be located, so the data is parsed into a more readily accessed form. Usually the data still bears a marginal resemblance to the original. Example of records in this state include Overworld Exits (and previously Location Events).
The most complex state is totally abstracted. Even a parsed form would be totally unusable to the display of the data (or make it much harder to use than is useful). The data will be converted and kept in a useful form in perpetuity. Conversion back to the original happens only in a temporary copy during save. This state is common for compound records like Events but is also used for records as simple as Strings. The new project approach keeps the data in this state permanently, even between sessions. This allows for several enhancements, such as storing meta-data directly in the record.
Flux has always used First Fit for bin packing. I had each of the separate record type saving processes manually ordered so that the typically largest record type saved first. But as of v3.00 it uses First Fit Decreasing. The records had been universalized, so I could tell an individual record to save instead of an entire record type. This allowed me to put them in a sorted queue and ultimately make much better use of the ROM's free space.
Flux maintains a Free Space map. This map contains all of the unused space, as well as all of the space used by editable, movable objects. On Save, the unmodified records claim their space out of the map. Then the modified records try to save themselves back to their previous home, if they can fit. If they do not, they will save to a new location.