No. The P6 keyword but, is not a boolean operator at all.
After a little more re-reading, this is my understanding, using my own terminology which may not match "official" terminology. (Please note: This may be wrong, though I don't think it is!)
but is one way to apply a Mixin to an instance of a class.
A Mixin, is essentially a partial class, a set of one or more methods that can be added to a Class, or an instance of a Class at runtime.
If applied to a Class, all new instances of the (derived or composite) Class will have the methods and data* of the Class PLUS the extra methods (and possibly data) from the Mixin.
*(I haven't used the "properties" or "attributes" words here because I'm still confused by what exactly each means in the context of P6)
If applied to an instance of a Class, only that instance gains the new methods and data.
A single Mixin can be applied to many classes.
The idea is that if you have a set of methods that will be useful in many classes, rather than
Adding those methods to every class and having to update them all when things change;
Using multiple inheritance with all the confusion (depth first -v- breadth first method resolution) and conflicts (which SUPER::method should be invoked if the main class doesn't provide a method, but two or more parent classes do?).
Or having to add every generically useful feature to the Base (Object) Class and burden every instance of every class with carrying that overhead even if they don't use it.
You place the methods (and any associated state data) into a Mixin (partial) class and then apply it to either whole classes or individual instances of whatever class as required.
The best example of use I have is the idea of a Storable Mixin.
Essentially, the concept of storing the state of an object is just a case of saving a few scalars (and maybe some arrays or hashes) to disk. Provided a class or instance can get a list of it's state data (introspect) at runtime, then the process of saving it to a flat file as CSV; or a DB as a BTREE; or an RDBMS using SQL is essentially the same for all classes.
What's more, by placing the Store and Retrieve methods in a separate module, it becomes trivial to replace the contens of that module--eg. replacing CSV with BTREE--as the needs of the application grow, and nothing else in the application need change.
The application can the apply the Storable Mixin to either whole classes or individual instances of various classes as required by the needs of the application.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon