Yes please! And it'd be even nicer if you exposed some of the config settings through the API too, like the key bindings.
They kind of are though? That's what GetPlayerKey() is, but nobody uses it because the current config.exe is clunky (and huge--take a look at a Sphere 1.5 distro some time--config.exe is literally the biggest thing there, even bigger than the editor!
). Unless you mean an API to
set the mappings, in which case... eh. I think at the point your game wants to do that, it means you're already exposing your own configuration UI anyway, so might as well go all the way and manage the settings yourself. Let's not invite scope creep here.
Also, input is kind of a complex beast. I was writing a long post asking for more full keymapping support that is analogous to modern gamepads, but thinking about it, this would NEED to come with a way to save the configuration in the game folder itself (and include it as a config in game.sgm or a config.ini in the same folder or something). Because some games have mappings where WASD moves you and the arrow keys do other stuff (or you need to use the mouse) while others would use the arrow keys.
The current config GetPlayerKey() mappings are already based on a gamepad (an SNES pad, to be specific: a single D-pad with four face buttons and a Start button--Select is MIA for some reason), so it would be easy enough to expand the mappings. The thing is though, again, Sphere's design is set up primarily for making retro games, so the conveniences provided by the engine reflect that. Anything more advanced, in my opinion, should be done in script. This kind of thing is why the File API exists (referring to the .ini-style File object, not RawFiles), after all.
It's probably a good idea to have the global config file which saves things like window scale and filter, and the game-specific section saves stuff relevant for only this game (like the input). I also think you can drop/not implement some stuff like disabling sound, because honestly, OSes just support disabling sound on individual apps now.
Oh! And sometimes you could expect different behavior from the keyboard and mouse compared to gamepads. You will want to stick with the raw keyboard input then. Sir Boingers is set up so that it both accepts the joystick API and keyboard input, but the keyboard input is all done with Sphere's keyboard-related functions because the game simply behaves differently when played with a keyboard. For example, on a keyboard, "up" makes you float, while with a controller it uses other buttons because that's easier.
However, I consider this a "don't worry about it" case as I've set up the game to check both the keyboard and gamepad anyway, and so should anyone else with controls that aren't the same on different controllers. They're more specialized cases.
I actually don't like the window scaling being global. It's one of my biggest peeves with Sphere 1.5--I generally keep 2x scale on because the majority of Sphere games are 320x240, but if I happen to come across one that uses 640x480 (or higher--T&E is 800x600!), the window is bigger than the screen and then I have to reconfigure it, which shrinks all my 320x240 games in the process.
Oh, and speaking of Sir Boingers, I'm actually not a big fan on the new control setup in v2. The 2010 version's setup was better, I think (Ctrl to bounce). A big issue with the new controls I've had is that, when bouncing and trying to move left and float at the time, the Up input gets ignored because of simultaneous-key limitations on cheaper keyboards (the keyboard on my Core i3 2-in-1 laptop, for example). This makes a few areas almost impossible and cost me a good number of avoidable deaths. I think this is why old console emulators used to use Ctrl and Alt for the face buttons, actually, since modifier keys don't contribute to the 3-key limit.