Raku provides a number of exception types that, on a conceptual level, are subtypes of each other. For example, X::Bind::Slice is conceptually a sub-category of X::Bind. But at an object-hierarchy level, X::Bind::Slice is not a subtype of X::Bind in Rakudo – it inherits directly from Exception. And for many exceptions, the thing-that-looks-like-a-supertype isn't even an Exception; e.g., X::Method is a Package.
On the other hand, X::IO is a Role which is done by various X::IO::* exceptions; thus X::IO::Copy ~~ X::IO returns True (unlike, say, X::Bind::Slice ~~ X::Bind).
Is there a particular reason for the various typing relationships implemented in Rakudo? (I say "Rakudo" because I'm not aware of any specs covering these relationships).
More practically, what sort of type hierarchy is advisable for my own exception types? My current practice has been to have a base MyModule::X type, with subtypes for different categories of errors, which in turn have subtypes for specific errors. (This approach allows for smartmatching against error categories, which can be handy). But that's pretty different than any of the approaches I see in Rakudo.
Am I missing a good reason to have a flat X::* hierarchy? Or, alternately, to have the "exception categories" be roles rather than types in the way X::IO is?