wow UNN you made that easy to understand!
My best, almost certain, bet, is that if you alter via a hexedit, the changes will occur in the 'game'.
This because, only non-exiting scripts, as in quote "one's in use at the time of the save" are actually saved in the fps.
that might incidentally, startle you, perhaps not. To give an example
fred.sqs
_thing=50;
exit
thing.sqs will not be found in the fps file (unless by extraordinary coincidence it happened to be 'in use' at the time.
Editing script files 'on the fly' can only happen if they are exiting scripts. One's that stay resident, eg anything on a permanent loop cannot. And the only way to change their behaviour is to hexedit. The fps file for this purpose, is much the same as saying 'resident in memory'.
This is not off topic for me because it leads back to the statement that exiting scripts, by their nature, are lag inducing (they cause a re read, re-binarise, of the 'file')
As for the very interesting decodes in your binview the 'strings' have associated with them an 'index number' a value you can clearly see in your example. It is these index numbers and these strings which make up the so-called 'binary' mission.sqms and are the object of affection in Amalfi's bin2cpp and cpp2bin utilities.
For me, the phrase re-interpret, means re-interpreting the strings present in the above tables you illustrate. Admittedly, considerably less cpu crunch overhead in interpreting them opposed to stripping out semicloons tabs and newlines from a text file, but re-interpreted all the same. There is no hash index construct to go directly to a given line entry. A shame.
So, now I guess it is wandering off topic and I'll take Macguba's suggestion to upload it as a submission.
Thank you all, for your input. I can see it's already been beneficial for people.