hmsong, looks good.
Event 301 sets flag FA to 01, so I think your change to Event 1DF is functioning more as a bug fix. In vanilla/VWF/Reloc, if you pick Sell, then back out and pick Buy, it should show the last visited shop instead of Neko's, and your change avoids that since flag FA is set before you can pick Sell.
There may be an issue with Event 65F calling Event 312; it was relying on Event 308 calling Event 310 to open the gold display. I haven't tested if this matters, just observing the difference between the different Neko events.
I doubt there are any potential issues with Event 318.
I spent the last few days generating those event dumps and integrating them into the Turbo ZPS. Going forward, it should make certain types of patches easier to make, and I'm currently modifying some older patches to use these new capabilities. As an example, the Orb_Overflow_Event fix went from needing VWF and Reloc specific fixups, to the following:
%OFF% Event508.Orb_Overflow_EventWhich automatically places it correctly for all 3 (technically %OFF% Event508 would work since this change happens on the first byte of Event 508, but I wanted to make it clear which feature was modifying Event 508).
\event \ret '\end
Regarding kethinov, he appears to strive for minimal necessary changes; I assume that he designs his changes with that in mind. If you have examples where you want to know how it was done, don't hesitate to ask. Some kethinov hack compatibility fixups were done by me so I may be able to give insight.
Probably the most "correct" would be to painstakingly figure out the bytes necessary for the VWF text; I've done this on occasion for a few features by brute-forcing the necessary values, but I both think this is overkill (I did so for "fun") and don't really know a good way to explain how I did it. It involved using an emulator where I could easily change ROM data while playing (Mesen-S), modifying an event so that it was stuck in a loop, and then changing the byte past the last correct letter until it was correct, then advancing to the next, and so on, until the text was correct.
reconstructingmana, regarding font width, fair enough, and it definitely makes it easier to plan text layout per text box with fixed. So that'll be 28 characters wide, by 3 lines tall. Player names max at 6 characters. I think those are it for the constraints with fixed width.
As for format, it's whatever you expect will be the easiest for translation; data creation by hand, which is functionally what translation amounts to, is tedious work, so having that phase be as streamlined as possible is top priority. Just as an example, if that means a spreadsheet for side-by-side boxes with, say, vanilla, Japanese, 2018 remake, misc notes, and retranslated text, okie dokey. In my previous post (3 up from this), I uploaded a zip containing event dumps in the exact format that will be used to insert this retranslation, but I do not expect it to be written in that format.
I think what would be most beneficial on my end would be if text could have its Event Number associated with it (using the spreadsheet example, if a column parallel with the text had its Event Number). I don't know if what you have on hand already happens to have their associated Event Numbers or not, and it wouldn't be impossible to use other existing data to match things up (like if the vanilla English text is parallel with its replacement), but having numbering available would greatly reduce the complexity of getting text put into the correct Events.
As for a sample, if you intend to use the same spreadsheet formatting as your prior work, a copy of the old would give me something to look at and see what my options are. I expect to write a script to process your data into something like the aforementioned event dumps.
For translation philosophy I like the sound of 3 the most; the effort is already substantial for any of those, but I would expect the third would be the most enjoyable (under the assumption that researching additional sources and figuring out how to work them in is a more rewarding experience than translation from a single source). To which I add that townsfolk text can be made as wordy as you want as I intend to add the ability to abort from simple non-essential dialogs with the cancel (Y) button; so some old townsfolk lady could ramble for 10 text-boxes-worth, but be able to be cutoff after the first.
I suspect I could create a facsimile of some of the remake's inn "cutscenes" as they're generally just the 3 characters talking in the inn room. This would be a significant time and effort investment, like, very significant to where it's a risk it wouldn't actually be practical, but it's worth bringing up now since information from said events could / would be relocated elsewhere if they're not implemented, and alternatively, I'd need to start figuring out how I'd be implementing them now if you do want them (deciding where save data holds which inn cutscenes you've seen would go, where in the inn events to check if you've hit a certain storyline event that triggers a given inn cutscene, which unused events are available to use for the cutscenes, etc.).