Intrigued by the various file-related pointers seen in deleteThisFile_EB9B, I remember that the keyboard scan routine had a final case where the bulk of the keystrokes (the printable ones) are handled, and there was a scan code to ASCII routine before handing it off.

EEC9             loc_EEC9:
EEC9 96 70           ldaa    byte_70
EECB BD F5 92        jsr     sub_F592
EECE 29 10           bvs     leave_EEE0
EED0 13 A1 01 03     brclr   bCapsLock_A1 1 loc_EED7 ; XXX CAPS lock flag?
EED4 BD EF BF        jsr     sub_EFBF
EED7             loc_EED7:
EED7 BD F3 07        jsr     sub_F307
...

so it seems plausible that sub_F307 would be 'stick it in the current file' to some extent.

F307             ; insert char A onto current file; V set if fail, clear on success
F307             insertCharToFile_F307:
F307 FE 01 24        ldx     curfileEnd_124  ; XXX file related (current file ptr end char (one past last)???) .4
F30A BC 01 26        cpx     thisFileRgnLast_126 ; this file; file region end addr (inclusive)
F30D 27 42           beq     leaveFileFull_F351
F30F FE 01 22        ldx     curfileIns_122  ; XXX file related (current file insertion point???) .0
F312 BC 01 24        cpx     curfileEnd_124  ; XXX file related (current file ptr end char (one past last)???) .4
F315 26 0C           bne     scootchFileUp_F323 ; if inserting into the middle, we have to scootch things up
F317 FE 01 22        ldx     curfileIns_122  ; (did we really need to load it again?)
F31A 36              psha
F31B BD EC 80        jsr     selectRAMpageForFile_EC80 ; select in the relevant RAM page based on file number (byte_15D)
F31E 32              pula
F31F A7 00           staa    0,x
F321 20 1F           bra     finishUp_F342
F323             scootchFileUp_F323:
F323 36              psha                    ; save char to insert for later
F324 FE 01 22        ldx     curfileIns_122  ; (did we really need to load it again?)
F327 DF 46           stx     scratch_46      ; save insert point in scratch var
F329 FE 01 24        ldx     curfileEnd_124  ; XXX file related (current file ptr end char (one past last)???) .4
F32C BD EC 80        jsr     selectRAMpageForFile_EC80 ; select in the relevant RAM page based on file number (byte_15D)
F32F             loop_F32F:
F32F EC 00           ldd     0,x             ; get two chars
F331 ED 01           std     1,x             ; store back up one byte
F333 09              dex
F334 09              dex                     ; bump down twice since we're doing two chars at a time
F335 9C 46           cpx     scratch_46      ; are we at the insertion point?
F337 2A F6           bpl     loop_F32F       ; keep going if not
F339 DE 46           ldx     scratch_46      ; get back the insertion point
F33B A6 00           ldaa    0,x
F33D A7 01           staa    1,x             ; do the last odd char
F33F 32              pula                    ; get back char to insert
F340 A7 00           staa    0,x             ; /now/ stick the char in
F342             finishUp_F342:
F342 BD EC 79        jsr     selectRAMPage0_EC79 ; select 32 KiB RAM page 0
F345 FE 01 24        ldx     curfileEnd_124  ; XXX file related (current file ptr end char (one past last)???) .4
F348 08              inx
F349 FF 01 24        stx     curfileEnd_124  ; increment cur file end pointer
F34C BD F2 06        jsr     sub_F206        ; XXX finish up after insert into file
F34F 0A              clv                     ; clear V for success
F350 39              rts
F351             leaveFileFull_F351:
F351 BD F3 56        jsr     showFileFull_F356 ; show File Full message
F354 0B              sev                     ; set V for fail
F355 39              rts

So it seems that word_124 is the 'current end of file pointer' and that word_122 is the 'insertion location pointer'.  These will be the same if you're inserting at the end, and different if not.

This pleases me a bit because I found the values at 120, 122, and 124 to be copies of the values in the fileState_12A array (array of three entries per file).  The ones at 120, 122, and 124 (and not in the same order) are for the currently selected file.  But we already know what is the currently selected file via thisFileNo_15D, so why bother having two copies?  This is one of life's little mysteries at this point, but it may become apparent later.  For example, I know there is an emergency 'undelete' facility, so maybe the copy in the fileState_12A array is used to restore the working copies in (120-124).  Just a guess -- have to dig it to find out for sure.

I also need to do a bit more work on sub_F206 which seems to be a final cleanup post insert routine.  If you're appending, it does nothing, but otherwise does do some work.