I'm going to need to chew on this a bit. From a general usage perspective, it doesn't matter at all. This is a hidden implementation details. From a debugging perspective when something goes sideways, I'm not sure. Let me talk / write out my thoughts and see if that helps.

If I just see that the matcher is a `Negation`, then I'd need to reach in and poke around to figure out what I was negating (though a `grep` on the code base could do the same thing sort-of). You don't have to worry about this normally, since `~` is in the spec and I can easily see what the inner matcher(s) are.

If I get back a `AliasedNegatedMatcher` that would provide a debugging clue that something was wrapped/duped/etc. Though I still have to poke around in the code to figure out what that was. So not a real win here either.

I think at the end of the day, I'd probably prefer to see `AliasedNegatedMatcher`. At least that's clear that this isn't a real matcher and I should look for the `define_negated_matcher` LOC, then try to look for a full matcher definition. Also, I _think_ (not completely sure), but if I do a full stack trace I'll see the line where the alias is defined, closer up the call stack.