More flexible inputs?
# Brain dump
## Additional buttons
I don't know the current reason why WASM-4 doesn't have it, but additional `BUTTON_3`/Select and Start/`BUTTON_4` buttons just like Game Boy would be useful.

## Disabled buttons
`SYSTEM_HIDE_GAMEPAD_OVERLAY` can be replaced by 4 bitfields containing usable buttons for each gamepad. This can be used to hide any buttons desired in the overlay (like the new 3 and 4 buttons), and multiple gamepads can explicitly be ignored by setting to 0.

## Pointless bytes?
Why are 2 signed 16-bit integers used to represent 25600 possible pointer/mouse positions? I haven't seen it being used for sub-pixel precision, like libretro does. How about a 16-bit signed integer, with -1 representing "not visible"? You can easily get X or Y from that.

## Inconsistent button maps + possible solution
`BUTTON_1` and `BUTTON_2` being treated in games as X and Z on the QWERTY layout is a bit problematic for the player who may be using a different keyboard layout or a gamepad. The mobile overlay currently doesn't label the buttons, either.
Here's a possible solution for this: The runtime stores multiple 8x8 1-bit button prompt sprites. The runtime can dynamically change the sprites as desired, and the player has a good time without additional setup. Doing that for multiple gamepads though (imagine a room with a QWERTY keyboard, AZERTY keyboard, and a gamepad with A & B) , is 64 bytes, which is excessive to say the least. Account for 3 & 4, and you get 128 bytes. --Are 2 gamepads not enough, anyways?-- Actually, this can be retrieved from a function instead of staying in the system memory. A more simple solution is to just label the buttons in the overlay and call it A, B(, Select, Start)... whatever.

Assuming breaking compatibility with current programs is not horrible, I hope you like some of these ideas!