@tmassman You seem like the closest to a dissenting view. I appreciate it.
I think you may have misunderstood my use cases. Serving a different image to twitter than what's displayed on the site is a good use of open graph, but this only covers when and where the URL of the image would be used (how to add it to the template), and not necessarily what resource that URL provides (where it points to).
Taking a featured / original image, but serving a cropped version of that image is supported, useful, and used, but is not the feature I am proposing.
No, it's not possible. Each version / scale is a transformation of the original featured image. It cannot be a new image or a different image. You cannot have a featured image of The Earth and a version / scale of that image being a human smiling.
"But this isn't want image scaling / cropping is designed to do". I totally agree, and that's the cornerstone of my own counterargument. This feels like I'm trying to break single-mindedness, SOLID design principles regarding image scales and the image cropper functionality.
We can accomplish this (and do) by having two fields on a content type schema. Both are type 'ImageFile'. One is 'featured image' and one is 'teaser image'. The teaser is displayed in listings and featured when viewing the object. When the teaser image is absent, we fall back onto image scales. Logic is provided in the view or template (preferably in the view).
However, from the view of a user, it would be very easy to 'upload' a different picture into a 'scale' of an image. I don't have to deal with an extra field on the schema. If the user has a firm understanding on how image scales work and are to be used, they know they are hacking the functionality of image scales.
Yes, this then changes the vocabulary from 'image scales' to 'image versions'. (thank you)
The advantage gained is a single place to control all versions of the "image representing the object". Depending on the context the object is used (default view, listing, mobile, twitter, facebook) it will show a different image version. We extend the functionality of 'image version' beyond just scaling and cropping by giving the user the ability to replace the image completely.
I am honestly on the fence here.
I feel this is a complete abuse of plone.app.imaging and making developing plone harder.
I also feel like this is a feature improvement that makes using plone better.
Creating a new add-on 'plone.app.imagescalemanager' (for example) to provide only the functionality to replace an image scale with a new uploaded image bothers me (a little) because I don't know how it would behave with plone.app.imagecropping also installed.
It also seems like a very clean user experience if the plone.app.imagecropping '@@croppingeditor' simply gains an 'upload' button.