March update: Everything for the Status screen is disassembled and stored in components/status, so when we go in there to make changes (and we will need to), check there.
The next component are the two phone-shaped menus, called TitleMenu and PauseMenu. In case I picked horrible names, TitleMenu code is called when you press start on the title screen, and PauseMenu is called when you press select on the overworld screen. These are considerably more complex than the denjuu status screen, so they won't be getting as in-depth a disassembly. Just enough that I can make sense of the ~40-odd changed bytes in that part of the ROM. So far I've found a complete renumbering of the phone input modes (for Latin input), the usual set of string relocations, as well as... a complete sprite animation system in use by the menus for putting cursors on things. There are literally over 200 different animations in this one table in C:7AC4, and I don't know exactly how the data structure that it modifies is used to generate actual sprites just yet. For the record, that last bit isn't actually something that was added in the patch. I just think it's a weird system.
I've also started work on documenting Telefang's per-frame state machine. Here's what I have so far - it's not yet ready for the Wiki, so it sits on Dropbox:
https://www.dropbox.com/s/0b4ffzugahyk3jb/states.txt?dl=0
For those of you who don't spend multiple days worth of time with telefang.gbc open in IDA, Telefang's gameloop calls into a massive three-level state machine that is responsible for running literally every screen in the game. With the exception of a few states that have separate variables for their jump tables, you can positively identify any screen in the game by looking at C3E0-C3E2. If you want to know what this code actually looks like, there's a disassembly in components/system/state_machine.asm of the top-level state system. Each function in that jump table then indexes another jump table using either C3E1 or it's own variable. Exactly one state is called per frame and it may change states at any time.
A state can do anything really, but usually you'll find that each screen has an "intro" state which fades things in (components/lcdc/fades.asm), then an "idle" state which reads controller input to queue up other states responsible for transitioning the UI, and finally an "exit" state which fades things back out before loading the next screen's intro state. You can actually keep the C3Ex line open in BGB and watch the state transitions occur while, say, the intro or attract screen animation runs.
It's actually really motivating to see that people still care about the project, and I think regular forum updates are a good idea.