DraStic

I investigated this a little more (but probably still need to look deeper still), here are some new thoughts:

DeSmuME's Lua engine looks very extensive (the .cpp file for it is over 6000 lines!) and I think covers a lot of functionality that goes beyond the scope that I'd consider tackling with this. There doesn't seem to be formal documentation and I don't think there's much in the way of publicly available scripts. So I don't think there's a ton of value in trying to maintain any compatibility with DeSmuME's native interface.

Emulator Lua scripting in general seems to have a big focus aiding TAS creation. Since I doubt there's any real desire to create TASes on mobile devices I'm going to consider this outside of the scope of anything I'd add to DraStic.

I've looked at FCEUX's Lua interface documentation and it seems pretty reasonable, although I doubt we'd come anywhere close to implementing as much they do, especially not at first. Another big difference is that they run it by having the Lua script be in control and "always" running, and responsible to update the emulator. I'd most likely implement it the other way, where the emulator calls a method in the Lua script once per frame. In this way it'd be a lot like cheat code processing, only the Lua script would have access to emulator state that the cheat code doesn't.

Yeah, I definitely agree that there's no reason to support TAS-like things. I didn't know DeSmuME had Lua scripting, but porting it over might be silly since the goal for this is much different.

I think the most benefit would come from being able to read touch/accelerometer input, write gamepad input, read/write memory, and modify the state of the onscreen controls. Some games that are otherwise unplayable would become super practical to play, in my opinion. Again, a great example being Okami, where you could read the region of memory that says "the paintbrush is active", display the bottom screen and hide the controls if it is. And the fact that it's a scripting language makes it practical for users to do this on their own and foster a community in it of itself.

I could also see access to modern input devices and RAM being useful because I suppose with some analysis of it's controls, SM64DS might actually be playable