There are pieces of 'custom' code that (want to) work / be implemented like a field formatter, except... they rely on the value of multiple fields.
And CustomElementsFieldFormatterInterface::build() gets a single field(ListItem) passed to its build() method, so we're stuck there.
Should we add a 'CustomElementsEntityFormatterInterface' instead?
The UI implications get fairly straightforward when 📌 Change configuration structure for CE display 'components' Active (and its UI task dependency) is done...
--
Example of this that I've seen in a CustomElementProcessor that processes a paragraph entiies of type 'image':
$media = $this->getDisplayableMedia('image', $paragraph->field_image->entity);
$lupus_image_data = do_something($media)
$lupus_image_data['zoomable'] = $this->isZoomable($element, $paragraph, 'field_zoom', 'field_image');
$element->setAttribute('image', $lupus_image_data);
(The actual logic isn't here, but you get the idea about both field_zoom and field_image being needed.)
Closed: won't fix
3.0
Code
I don't think that's worth it. IT's conceptualyl complicating things A LOT for some special cases because of BC reasons. With the new model, we most likely would have built it differenty simply. For those special cases, auto-processing and custom processors is still doable.
Let's not do this until we 100% see the need for that.