local coordinates (^ ^ ^5) require an entity even after execute-facing

Put the following command in a command block and activate it:

execute at @p facing ~ ~ ~2 run summon pig ^ ^1 ^5

EXPECTED

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.