I know you're interested in rewriting the settings API, but here's a few things I noticed and features that may be useful to include in the future. I'm happy to write a PR for all of these.

Settings Events

Events should be fired when settings are changed, saved, loaded, etc. The most useful event would be settings_changed that returns a table of settings keys that changed (optionally with old and new values, but this is a luxury). More specific events for each type of action could be included too, including settings_save, settings_load and settings_clear.

This would be useful for programs to automatically update their own variables or refresh their user interfaces when a setting is changed, e.g. from the shell command. A more specific example would be my street sign program, which is managed via the settings API - it would save the user having to restart the computer by catching a settings change event and redrawing the sign immediately.

Settings Save

Settings tend to be saved in /.settings (for example, the BIOS loads user settings from there). However, the settings.load and settings.save functions require a path to be specified. While this functionality is definitely useful, I think it would support a more common use case to save and load to the /.settings file by default, and having the path be an optional argument. I am not sure if this was a deliberate design choice by dan200, or an oversight.

I know you're interested in rewriting the settings API

Just to clarify with this, I want to find a nice way to disambiguate between settings which have been defined (such as those set in the bios), and those which have actually been changed (i.e. set in .settings). Ideally .settings would only store changed settings (rather than the entire state), and unset would reset to the default value (rather than clearing entirely).