more set/bag list clarifications

We're not trying to override explicit @ or .keys here, merely the
implicit policy for a default of item in list context.

Also, set/bag constructors are simply slurpies, and shouldn't care at all
what was passed as the objects in those slurpies.  Generally one should
be using "union" to combine sets or bags anyway, not relying on implicit
constructor semantics to do that.

Author: TimToady

S32-setting-library/Containers.pod

@@ -1113,11 +1113,14 @@ See C<KeySet> for a container that can represent different sets as
 keys are added or deleted.
 
 Regardless of their behavior as hashes, set (and bag) types do not
-flatten in list context; they are returned as items in list context.
-On the other end, the constructors for set and bag types do not
-automatically interpolate the contents of sets or bags (or any other
-other item type).  Together these rules allow us to constructs sets
-and bags containing sets and bags as elements.
+flatten in list context; in the absence of explicit interpolation
+instructions (such as use of the C<@> sigil or C<.keys> method)
+they are returned as items in list context.  On the other end, the
+constructors for set and bag types do not automatically interpolate
+the contents of sets or bags (or any other other item type).  They
+simply take the list of objects slurped in and turn them into a set.
+Together these rules allow us to constructs sets and bags containing
+sets and bags as elements.
 
 =over