Should be self explanatory enough. Positive checks forward, negative checks backward.
You can change the direction using “point in direction x” and then set it back when you're done, if you want to check a different direction than the one your sprite is currently facing.
Edits:
Edited to have circle dropdowns, which have way more usability
Edited to have steps instead of a specific x axis check for the workaround

<(all of v) sprite (Sprite2 v) is (3) steps away? :: sensing>
<(clone of v) sprite (Sprite2 v) is (3) steps away? :: sensing>
<(main v) sprite (Sprite2 v) is (3) steps away? :: sensing>

While there is a workaround…

define collision (steps) // Run without screen refresh ON
move (steps) steps
if <touching (Sprite2 v)?> then
...
end
set [Is Touching? v] to (<touching (Sprite2 v)?> + [0])
move ([0] - (steps)) steps

… I feel like it could be better practice for a native “raycasting”/“detection” block to be added.
If you need me to elaborate, then I will!

How often would this be used, enough to justify not just using the workaround?

I kinda thought you would use the pythagorem theorem (a^2+b^2+c^2) for the workaround

zispe wrote:

How often would this be used, enough to justify not just using the workaround?

Often
It allows for detection of different types of blocks and makes it easier to detect certain things in a specific radius, which the <touching sprite?> is not equipped to do well. That one is specific, and should stay how it does already. Being able to “fire” raycasts instead of “simulating” them would reduce how clunky detecting sprites is. Collision, raycasts, mazes, etc.

what about this?

<(distance to (Sprite2 v)) = [3]>

while the clones would have to detect how close they are to the other sprite