Good way for customizations to register settings to a unified settings page

Ideas
1

I’ve recently started using silverbullet and I’ve found that the configuration is often quite daunting, even for relatively simple things. I’ve been thinking about a way that customizations (and even the silverbullet itself) could register their settings to a simple settings page, and I got a little ways, but not far enough to be useful as it is.

I figured I’d share what I had, and my vision, and see how this idea could be improved on, or if there was even appetite to provide out-of-the-box support for something like this.

The idea is this:
Instead of hard-coding the configuration directly in the setup script for your customization, use the markdown page as a config file that the setup script (on the same page) queries.
The advantage here is that you have a declarative (easy to understand) configuration, and also that other pages can query and present the configuration. I imagine having a common unified setup page where you can go to modify all the configuration for your silverbullet app.

I got this working for boolean configuration, because the taskitem query template will let you edit the task state on the original page. I couldn’t figure out how to recreate this for other object types, and I likewise couldn’t figure out how to group these settings by page, both of which are pretty large blockers that I’m hoping someone knows how to solve.

here is what I have so far:

---
tags: config
---
## properties for this customization
[ ] myProperty1 describe the property here
[ ] foo.bar.baz describe what this is

## implementation
```space-lua
pluglist = config.get("plugs") or {}
table.insert(pluglist, "urlToMyPlug")
config.set("plugs", pluglist)

for prop in query[[ 
     from index.tag "task" 
     where page == _CTX.currentPage.name
   ]] do
    config.set(prop.name:split(" ")[1], prop.done)
end
```

and then in a common setup page you’d have something like

## silverbullet properties
${some(template.each(query[[ 
    from index.tag "task" 
    where table.includes(itags, "config") 
    order by page, name]], templates.taskItem))
    or "No Properties"}

My end vision is that adding a plug becomes as easy as importing the (conforming) config page into the config directory (which is hidden from navigation), and then going to the unified settings page to change any defaults.

Does anyone see a way around the blockers I described?
Does this seem like a valuable convention that customization devs should adopt, or should be encouraged/made easier by the silverbullet itself?