The current extensions concepts are roughly defined as follows:

• Multiple extension types (user defined types, type variations, scalar functions, aggregate functions, window functions, etc). This list is likely to expand.
• Extensions belong to an organization. Currently conceived as a global list of organizations maintained in substrait with pointers to a publically available toc defined as a github url. A portion of organization ids are considered private extension ids that can be used for internal/private resources and implementations.
• Each organization manages a TOC, which then lists out 0 or more locations for each extension type to get the definition of the extension.
• Documents are all encoded is relatively simple yaml documents (with schemas that can/should be formalized).

The model is trying to achieve two things:

• Make extensions as independent as possible: once someone registers an organization, the specifics of what they house in that organization are entirely independent of any central control.
• Maintain a root list of organizations so that people can find things that are being used and collaborate rather than always reinvent.

As I think through the initial sketch, one of the things that I dislike about it is that really isn't a good reason to have a numeric id associated with each organization. This was done for encoding reasons but the reality is that we can come up with a rudimentary plan level scheme to achieve the same thing without having to keep a list of canonical numbers.

A couple key questions asked by others include:

• Do we need a central list? Why add that overhead? If we want to have a list of commonly used things, we can maintain that but it shouldn't be used as a blocker for extension (I have to request to be registered before I can begin extending things).
• Can we do harder coupling of git uris so that organizations, list types, etc. Basically are well-known. In general moving more towards further towards convention over configuration. For example, one would simply source github.com/package-url/packageurl-substrait and then all of the assets (functions, types, etc) would be available for plan inclusion.

I'll add breakouts for these and some other similar questions.