Starting to argument from the statement that junctions are values
the above plays in the league of 3.() which might not have observeable
side effects other then busying the compiler for a while. Actually
it could be optimised away :)

Unless you ask a question nothing is called. So at least you need
something like if one(...) {...}. Then the call order is undefined
and might stop after the first success. Knowing about the constness
of the return values of the subs referred to from the junction, and
knowing that none of their values is false, these cases might be
optimized towards the front when this stops the influx of further
interrogation by the if. The reverse might apply for interrogation
by unless---but that's up to the oracle :)
--
TSa (Thomas Sandlaß)

IIRC the .perl method produces a string from which an equal value
can be recreated, so e.g. $result == eval( $result.perl ). This forces
a once through evaluation of the junction. So, yes I think your result
is one of the possible 4. The other three are the two numbers in the any()
swapped and the number and the any() of the one() swapped.

OTOH, the junctions will be stored before the .perl call as e.g.
one(any(Ref of Sub, Ref of Sub), Ref of Sub) with the three subs
beeing mutually different. The .perl method might then just be
propagated down to give e.g. 'sub { $a + 1 }' and not call the subs.
But I've no idea how a closed over value is printed. So it could
also be 'sub { \0.5 + 1 }' or 'sub { $Full::Path::To::a + 1 }'.
This is coupled with the questions how references work and how they
are printed.

What I don't like of the Junctive Debates is that many people think about
junctions as specific forms of list. And I haven't managed to understand
the relation between MMD and the code warping needed to get autothreaded
junctions.
--
TSa (Thomas Sandlaß)