A proposed alternative model for the registry

New here and lacking historical context, so please bring your tribal knowledge. CC: @oddhack

While old, #19 is interesting. I'm seeing a need to define the registry such it appears in the form most conducive to its consumers while keeping it maintainable. Unless there's a development I missed, right now things look lose-lose for a few cases.

On my end I could not just use an XML parser to back FFI binding generation. I needed to parse C too (1, 2). Right now if I want to simplify my job I need to either get buy-in to add more stuff in vk.xml for my purposes at maintainer expense, or spend enough time on a hybrid parser that I may as well write bindings by hand.

Spitballing here, but what if the registry starts with a Scheme that only models a dependency graph for named concepts? A reverse topological sort then yields a sequence of declarations to inform generation of C headers, or a conversion of the spec to XML, JSON, etc. Using a Scheme is just meant for language extensions when semantics get strained.

I think this model can change the user/maintainer relationship in a good way. In that scenario the onus is on maintainers to model the registry in a language-agnostic way and still generate vulkan.h etc., but it can also place the onus on consumers to do something else without needing maintainers to juggle implementation details for external projects in the same place.

It's possible that I am not communicating what I'm envisioning clearly and can understand if there are still doubts about the benefits. But if I prepared a POC of smaller scope, would you want to see it?