For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.
Entity Reference allows using a View of a specific display type to set the available options. This is good.
It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.
Those arguments must be completely static. This is not good.
Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.
That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.
Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:
1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.
2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.
In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.
(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)
Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.
So:
1) Is this feature something that would be accepted?
2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)