Put the following command in a command block and activate it:
execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5EXPECTED
summons a pig at location ~ ~1 ~5 from the player (at their position, facing positive Z, local ^ ^1 ^5)
ACTUAL
command fails, error in block is:
[14:09:27] An entity is required to run this command here
More generally, I expect that 'facing' should override subsequent carets, in the same way that `at` or `positioned` override subsequent tildes (and default x=,y=,z= in selectors).
LATER...
After a few days mulling, I think I grok the purpose of 'anchored' better now. In particular, if I want to use a teleport to change @p's rotation so that he is facing a baby zombie standing over yonder, I see that there are four possible rays (my eyes to zombie eyes, my feet to zombie eyes, my eyes to zombie feet, my feet to zombie feet) which correspond to four distinct angles. 'anchored' provides an incoming context by which to choose the origin (my eyes/feet), and tp's facing argument of eyes/feet provides a way to select the destination.
I guess the current system is fine, except that it would be really nice if, if @s is null, then 'anchored' computations are done 'as if @s were a zero-tall entity', that is eyes=feet, so that entity-less local-coordinates (a useful feature in prior snapshots) are still able to be used. That's the crux of this bug.
I'd like to note that the workaround to this bug is using `as`, which is not something that should be required for anything related purely to position/rotation. Even if taking advantage of the `anchored` subcommand, the command executor should not be involved (store the height data in the command "source", separate from the executing entity. If there is no entity, make `eyes` the same location as `feet`). I'm not sure if the existence of `anchored` (and the fact that by default it's `feet`, in contrast to being a position) is the cause of this issue, but I did want to throw that out there.