Reword Junction short-cuircuting portion

Closes #2120 D#2120
- Expand short-circuiting behavior to include same type of shortcircuiting as
    performed in `and`/`or` ops
- Document it as possible future language feature per
    #2120 (comment)
- Feature proposed in R#1963 rakudo/rakudo#1963

doc/Type/Junction.pod6

@@ -57,11 +57,18 @@ C<Junction> come into play:
     say so %h{one <foo  bar>}:exists; # OUTPUT: «False␤»
 
 Note that the compiler is allowed, but not required, to parallelize
-and, where possible, short-circuit autothreading (and Junction behavior
-in general), so it is usually an error to autothread junctions over code
-with side effects. When short-circuiting is involved (e.g. when evaluating
-a L<Junction> in boolean context), its order is not guaranteed and is done
-for performance purposes only.
+autothreading (and Junction behavior in general), so it is usually an
+error to autothread junctions over code with side effects.
+
+It is possible I<future language versions> will include short-circuiting
+behaviour in Junctions. For example one or more routine calls (C<a()>, C<b()>,
+or C<c()>) in the code below might not get executed at all, if the result of
+the conditional has been fully determined from routine calls already performed
+(only one truthy return value is required to know the entire Junction is true):
+
+    if a() | b() | c() {
+        say "At least one of the routines was called and returned a truthy value"
+    }
 
 Junctions are meant to be used as matchers in boolean context; introspection
 of junctions is not supported. If you feel the urge to introspect a junction,