To answer the question by yeoldeusername, patching to the base and complete versions and then expanding the ROM to accommodate the translation - that's what I've been doing. I cannot fit the translated script in the original space provided, and FF3usME points the original dialogue pointers to the new space, but any patches that include direct links to dialogue pointers break as a result. The King of Vanity patch is the earliest point in the game where this occurs - I can go through the source code provided with patches to see if there are any others (the Shadow in the Veldt patch comes to mind), but some of the patches don't have source code provided in the readme or documentation with the patch.
The hex editor I use, Windhex, can do a diff between a clean ROM and an edited one (I think, anyway), so if it's possible I can do a diff for all the patches that might affect dialogue and see what's happening - but without new memory addresses to point to, I'm not sure how I could fix this.
That makes sense. I've been using FF3usME for a while without understanding the inside workings or even anything about assembly or SNES ROM data structure. So it's nice to be able to find a live thread and learn something.

Anyway, I did a little looking and found this:
http://www.rpglegion.com/ff6/hack/ff3info.txt0CE800-0CE801 (CCE600-CCE601) DATA Index of the pointer in which the bank byte needs to be incremented
0CE802-0D01FF (CCE602-CCFFFF) PTR Pointers to Dialogue (+0D0200/+CD0000)
0D0200-0EF2FF (CD0000-CEF0FF) TXT1 Dialogue (3326 items, variable length)
So what I understand is that FF3usME moves the TXT1 (CD0000-CEF0FF) to new space added at the end of the ROM (or at least extends it at the end of the ROM). And adjusts PTR (CCE602-CCFFFF) accordingly? But PTR does not move, so I would think a hack referencing the PTR would not be affected. Am I right so far?
The King of Vanity changes are pretty well documented, and it looks to me like mblock129 essentially references PTR, not TXT1 directly. I.e. he calls 4B 07 05, 4B being the dialog command and 07 05 being #0507, which is caption 1287 - 1 = 1286. Same for 4B 08 05. That's the same way the original code initiated the dialog.
When you say this:
This is why the King of Vanity scene hangs, right when it's about to start a new line of dialogue.
Do you know this from debugging or just from observation of the gameplay? Do you know the exact line where it fails?
Is it possible that the conflict has nothing to do with the dialog but instead has to do with the free space mblock129 uses for his extra code? Maybe it conflicts with a different patch? He uses CC/FED0 through CC/FF24 (D00D0-D0124). Or maybe it's a bug in his code that manifests itself after a different mod tinkers with palettes or what have you.
With respect to Shadow on the Veldt / Shadow is not a Girl, mblock129 changes a (normally) unused pointer in PTR to point to some random free space where he stores the raw text data for the male version of the caption (at EF1E6 raw location). My guess is that FF3usME overwrites the whole PTR section (CCE602-CCFFFF), presumably overwriting unused pointers with #FFFF or #0000. If that's the case, it might work to apply the patch after the FF3usME town dialog expansion. (Assuming there are no conflicts with the free space mblock129 uses...)
Or even easier, just rewrite caption 2578 to be gender neutral (just throwing that idea out there...). Besides does your translation patch have the same wording as the original for this caption? If not, then mblock129's Shadow version won't have parallel wording to your translated Relm version caption.
Or, you could change mblock129's patch to reference an existing PTR for an unused caption somewhere within the existing town dialog bounds. Then you can edit the text of that caption and remove the part of the Shadow patch that copies the text data to a random unused location. You would have to use the same caption in the standard and translated scripts, but hopefully it would be a one time change that would stick and work.
So to answer your original question (hopefully), here's how you change a reference to a town dialog pointer:
- Find the location of the reference (in these cases, mblock129 gives us the locations).
- The byte with value 4B indicates the command to go look up a caption via a pointer.
- The two bytes after 4B indicate the pointer / caption number, kind of.
- For example, 4B 07 05 indicates caption #0507. And yes the 07 05 is backwards from #0507, because Assembly.
- Convert #0507 to dec and subtract 1 to match FF3usME numbering (the first dialog pointer is #0001 whereas first FF3usME dialog caption is 0). So that would be 1286 in this case.
- To change 07 05 to something else, select the FF3usME script caption you want to reference and then backwards calculate the two bytes that you need to put after the 4B command.
- When FF3usME imports the script, it will calculate the caption locations and update the pointers accordingly, so you don't need to know exactly where your caption will end up, just the corresponding pointer number.
Keep in mind I've never gotten to this level before, so I could be missing something here...