I'm re-scoping this in terms of Menu Customizer which was added in 4.3 but also without all of the necessary hooks to be extensible for plugins to easily add new controls. The latest work there was done in #32832 and #32708.
In any case, adding new menu item types and adding fields to existing menu item types should ideally have the same interface whether the extensions are targeting the menus in the customizer or menus on the admin page. Maybe this isn't realistic, but at least there should be parity between the two. I know this also gets into Fields API territory.
On #32832 (comment 16), I put down some thoughts on what needed to be done for menus in the Customizer:
- Extend
WP_Customize_Nav_Menu_Item_Setting::value() to allow plugins to amend the normal value with additional properties, where the filter can draw the properties from postmeta.
- Allow for custom fields to be inserted into
WP_Customize_Nav_Menu_Item_Control::content_template().
- Allow custom fields to be linked to the new properties in the
nav_menu_item setting value, using a similar approach to the link method, although again here we're dealing with sub-properties of a setting, not entire setting value itself.
- Extend
WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item() to amend the returned WP_Post object with the additional properties.
- Extend
WP_Customize_Nav_Menu_Item_Control::sanitize() to allow the amended values to be sanitized.
- Extend
WP_Customize_Nav_Menu_Item_Setting::update() to allow the amended values to be persisted (in postmeta)
I also put forth an assumption that the data source for any menu item custom fields should be sourced from postmeta.