Introduce 'display' as a way to group and reuse instance and formatter settings.

Weight should definitely be 'by context' - including 'forms'.

As you point out, this raises the issue of the explosion of weights you need to define for each 'build mode' (full, teaser, rss, search index, 3rd party build modes, user-defined build modes, etc...). This applies to display options and formatter settings too, for that matter.

Here's the big plan I had in mind :
- weights and display settings are not tied to 'build modes', but to 'displays'.
- a 'display' is a collection of field ordering and display settings (formatter + settings, label display mode...), assigned to a given bundle. Each bundle has its collections of displays.
- fieldgroups would also be 'by display' : you can have different grouping on forms and on various displays.
- 'build modes' are assigned to displays : 'teaser' uses display 1, 'full node' and 'rss' use display 2, etc
- each bundle has a 'default display' : weights and display settings that are used for all build modes that do not specify otherwise (or for instance because the 'build mode' is exposed by a module that's just been enabled). Users can add additional displays and assign to fit their needs.

This IMO gives the best flexibility while keeping a manageable UI experience (much simpler than the one we currently have) :
you can specify that 'article' nodes will use specific display settings for teaser, and the same settings for all other modes, and something different for 'page' nodes.

Now, how do we get there ?
I think core can live with only the notion of 'default display' : *one* set of display settings used for all build modes :
- CCK brings the notion of additional displays (and the UI and settings storage that goes with it).
- When a field is about to be displayed, field_default_view() lets contrib modules hand the display settings that must be used.

This means more or less what you propose above, except for the 'weight_override' part :
$instance['widget'] has a 'weight' property that's used for forms
$instance['display'] is not anymore :

- (context_1)
  - label
  - exclude
  - type
  - settings
     - ...
- (context 2)
  - ...

but just :

- label
- *weight*
- exclude
- type
- settings
  - ...

Brilliant idea. I think TinyMCE has a similar notion of a settings group that gets reused. Or at least it did a few years ago.

Probably far fetched for D7, but belongs to field_ui now.

Suppose this issue should be marked as closed(fixed)

Still on my hitlist for d8

Hi,

Was not aware of this issue so I thought about this as well ...
I came up with the same reasoning as in #2. So generally A display object with its own storage is the biggest request here.
The thing I did not have was the link between view mode and display (in my reasoning the view mode == display, but that would not work properly).
So basically #2 is a great solution imo. If we go that way, it's all about responsibilities.

What I also think is that view modes should be shipped in core as they are already introduced in core. Views in core is just another major decision maker on the view modes in core.

Other remarks following #2:
- All contribs adding stuff to the field UI screen (like fieldgroup, ds, ...) would need to cleanup the saved configurations for all view modes / entities. This is not that hard.
- Field formatters which come from contributed modules is a hard problem, especially since the formatter is not there anymore and should be set on "default", but what is default ... . In some cases this is how it was configured before the contrib providing the formatter came along. So this is something to think about.
- This makes it also possible to have a different Display object, E.g. a module comes around who leverages a new FIELD UI, very much as we know the page manager. This can be display suite or some other module providing the "advanced layout".
The question then is 1) Do we overwrite the original display settings so the reading code stays the same, or 2) Do we need a simple bridge that just reads out the advanced display settings. (In this latter case we can just disable the advanced layout and everything is back as it was).

Just some thoughts. Let me know if some decisions already have been made. I'll help everywhere I can (DrupalCon Munich gave me this very positive boost)

Referencing #1812720: Implement the new panels-ish controller [it's a good purple]. Imo they can be developed totally separate from each other, but the information found there is interesting for this issue.

Closed in favor of #1852966: Rework entity display settings around EntityDisplay config entity which has the patch.