Our original scope was to provide an API for adding form UI elements for post metadata. Historically in core, there is a simplistic UI for editing custom fields: a meta box on the Edit Post screen with textareas for each field's contents. This shows how unopinionated core has been in regards to metadata. From a developer's perspective, getter and setter functions exist with basic sanitization and authorization and that's it.
Core's unopinionated respect towards metadata is actually a good thing. It's opened up a vacuum for third-party libraries to fill in with a wide variety of solutions that employ different architectural patterns.
To take insight from these libraries, we researched their architecture to uncover desirable architectural patterns for a core-worthy plugin.
These libraries include: Custom Metadata Manager, Pods, Custom Metaboxes and Fields, Humanmade’s Custom Meta Boxes, WPAlchemy, Advanced Custom Fields (ACF), Custom Field Suite, Types, FieldManager, Super CPT, Easy Custom Fields, WordPress Settings API Class, piklist, Option Tree, vafpress-framework, wp-forms, Sunrise, Advanced Post Manager, Themosis, oik-fields, Tax-Meta-Class, MetaBox, KC Settings, Developers Custom Fields, Simple Fields, Nmwdhj, BMoney Custom Meta Boxes, WordPress Extend (WPX), WordPress-Cuztom-Helper.
We invited authors of these libraries to present an overview over Google Hangout of their library and anything of note that came up architecturally in development. All these can be found in a Youtube playlist.
We also wrote up architectural overviews of these(time/effort permitting), so we could compare architecture at a glance rather than diving into code. Fieldmanager, Custom Metadata Manager, Custom Metaboxes and Fields, WordPress Extend (WPX)
Although this is a project by the Metadata component team originally scoped for creating a post metadata UI API, basically what we are creating is a form element-building API with a contextual form handler. A form handler has utility in other places in the administrative area, such as settings pages, taxonomy term metadata, Theme Customizer fields, etc. The form handler should be extensible and versatile enough to support any context, including a generic front-end form.
To this end, we endeavored into architectural reviews of core APIs. See Settings API, Theme Customizer API(currently being written).