Often there are situations whether the user will want to specialize a method in some argument position for a specific object. There are various reasons to do this, and various factors to consider when deciding to do so.
Two common patterns where the developer wants to specialize to a single object usually emerge after extended usage. First, there are domain objects which naturally have special non-sharable behavior. For example, True is clearly a particular object that helps define the semantics of the whole system, by representing mechanical truth abstractly. In other situations, the same pattern occurs where one has a universal concept, or locally an absolute concept within a domain.
Second, there are situations whether the user is demonstratively modifying the behavior of some thing in order to achieve some prototype that behaves in some situation as they desire. Depending on whether the user decides to share this behavior or not, the instance-specific behavior may or may not migrate to some shared Traits object. In either case, this is an encouraged use of objects and methods within Slate.
There are factors which weigh against the use of dispatch on objects with non-shared behaviors. Generally, these just amount to a few simple reasons. First, the behavior will not be shared, which is obvious, but sometimes not clear to the author. Second, the author may mistake an object for its value or attributes, such as Strings, which are not unique per their value, and so get unexpected results if they dispatch on a String instance. The same is true for all literals of that nature, with the exception of Symbols.
The general rule for defining a method on an instance which is a lightweight ``value'' object, is that the object must be reliably re-identifiable, as Symbols are for the language, or through naming paths from the lobby or some other object that the user is given access to, such as a method argument. Otherwise, the user must be careful to hang on to the identity of the given object, which offsets any polymorphism gains and exposes implementation details unnecessarily.