Clarification still needed for Set, Bag, etc coercion funcitons

Previously, the Set (etc) constructors, given a list would act as each if item in the list had been passed individually to the constructor, and so on recursively. Hashes, Sets, etc would do the same with their keys, Pairs with their key.

Current behavior (NYI anywhere) is any object passed to the Set constructor is stored in the Set as that object. This allows Sets of Sets, Sets of Hashes, Sets of IO, Sets of Any, whatever. To get something like the old behavior, you use the .Set coercion method instead.

But as I understand it, that "something like" is very important. In particular, my impression is that these new coercion methods do not recurse like the old constructors did. Specifically:

 set(set(1, 3), set(2, 4))

previously created a Set equivalent to set(1, 2, 3, 4), because we recursed into the keys of each Set. Now it creates a Set with two Sets in it. I'm thinking

 (set(1, 3), set(2, 4)).Set

should probably also return a Set with two Sets in it. (Please let me know if this assumption is wrong!) What about

(1, 2, 3, [3, 5, 6]).Set

-- is that a Set with four elements, one of which is an Array? Likewise, how about

(a => 10).Set
(3..10).Set
(1, 2, 3, 3 => 10).Set
(1, 2, 3, 3..10).Set
(1, 2, 3, %hash).Set
{ a => 3, b => 2000 }.Set

You can ask all the same questions again with Bag, KeySet, and KeyBag. I presume that

(a => 3, b => 2000).Bag

produces a Bag with 3 a's and 2000 b's. It frankly strikes me as bizarre that there is no longer a spec way to create that with a direct Bag constructor. (Incidentally, this means Bag.perl must return strings of the form (mumble).Bag.)

Raku / old-design-docs

Clarification still needed for Set, Bag, etc coercion funcitons #44