+@a/+a slurpies produce inconsistent results

[zoffixznet]

The +a and +@a is raw slurpies look equivalent, however, anyway I slice it, I see results as inconsistent:

• When we're doing raw, why is it converting Array to List?
• When we're not doing raw, why is it converting List to Array, but converts Seq to List?
• Does it make sense to have a Seq in a @-sigiled param, since it's not Positional and it's
  also uncached, which could lead to surprising bugs where trying to work with a @foo makes it
  explode with errors about consumed Seqs (originally reported in RT#131483)

What's the correct behaviour here? This affects some core routines, like &list (#1344), which makes speccing their behaviour difficult.

         -> +l { l }(  [1, (2, 3)]      ) = (1, $(2, 3))
         -> +l { l }(  (1, (2, 3))      ) = (1, (2, 3))
         -> +l { l }(  (1, (2, 3)).Seq  ) = (1, (2, 3)).Seq

       -> +@l { @l }(  [1, (2, 3)]      ) = [1, (2, 3)]
       -> +@l { @l }(  (1, (2, 3))      ) = [1, (2, 3)]
       -> +@l { @l }(  (1, (2, 3)).Seq  ) = (1, (2, 3))

-> +@l is raw { @l }(  [1, (2, 3)]      ) = (1, $(2, 3))
-> +@l is raw { @l }(  (1, (2, 3))      ) = (1, (2, 3))
-> +@l is raw { @l }(  (1, (2, 3)).Seq  ) = (1, (2, 3)).Seq

$ perl6 -v
This is Rakudo version 2017.12-11-g2a8287c built on MoarVM version 2017.12-1-g912f967
implementing Perl 6.c.

Code used to make the chart:

.not ?? say() !! printf "%41s = %s\n", $_, .EVAL.perl for
｢-> +l { l }(  [1, (2, 3)]      )｣,
｢-> +l { l }(  (1, (2, 3))      )｣,
｢-> +l { l }(  (1, (2, 3)).Seq  )｣,
'',
｢-> +@l { @l }(  [1, (2, 3)]      )｣,
｢-> +@l { @l }(  (1, (2, 3))      )｣,
｢-> +@l { @l }(  (1, (2, 3)).Seq  )｣,
'',
｢-> +@l is raw { @l }(  [1, (2, 3)]      )｣,
｢-> +@l is raw { @l }(  (1, (2, 3))      )｣,
｢-> +@l is raw { @l }(  (1, (2, 3)).Seq  )｣

[smls]

Here's the behavior that I think would be most useful, in particular taking into account the concerns of issue #1398:

	+a	+@a
When passed a single non-containerized Iterable arg	like \a¹	like @a is copy²
When passed any other single arg	as a List	as an Array
When passed multiple args	as a List	as an Array

_{1) I.e. preserve the argument as it is.
2) I.e. do the PositionalBindFailover thing. The is copy, which corresponds to current behavior in that case, is to prevent surprising action at a distance when the routine shifts from its argument list and downstream code passes an existing Array to it.}

This way,

• +a would be "\a plus Single Argument Rule convenience"
• +@a would be "@a plus Single Argument Rule convenience"

---

As for @a is raw, I agree that allowing it to bind a non-Positional value to a @ variable is bad, because that breaks the contract that users expect @ variables to uphold.
So it shouldn't be a synonym of +a.
Either make it like +@a but creating Lists instead of Arrays, or - which I would recommend - deprecate it, leaving only the two options shown in the table above...

[zoffixznet]

So it shouldn't be a synonym of +a.

Note that doing so would create inconsistency with how **@foo slurpy behaves. There's no **foo variant for it (don't know why), so is raw is the only way to avoid containerization.