module T::Private::Abstract::Hooks

def append_features(other)

is important for our validation).
`included` hook, but this gets calls before the ancestors of `other` get modified, which
It gets called when *that* module gets included in another class/module (similar to the
This will become the self.append_features method on a module that extends Abstract::Hooks. 
def append_features(other)
vate::Abstract::Data.set(self, :last_used_by, other)

def extend_object(other)

is important for our validation).
`extended` hook, but this gets calls before the ancestors of `other` get modified, which
It gets called when *that* module gets extended in another class/module (similar to the
This will become the self.extend_object method on a module that extends Abstract::Hooks. 
def extend_object(other)
vate::Abstract::Data.set(self, :last_used_by, other)

def inherited(other)

It gets called when *that* class gets inherited by another class.
This will become the self.inherited method on a class that extends Abstract::Hooks. 
def inherited(other)
f` may not actually be abstract -- it could be a concrete class that inherited from an
ract class. We only need to check this in `inherited` because, for modules being included
xtended, the concrete ones won't have these hooks at all. This is just an optimization.
 if !T::AbstractUtils.abstract_module?(self)
vate::Abstract::Data.set(self, :last_used_by, other)

def prepended(other)

It will get called when *that* module gets prepended in another class/module.
This will become the self.prepended method on a module that extends Abstract::Hooks. 
def prepended(other)
ending abstract methods is weird. You'd only be able to override them via other prepended
les, or in subclasses. Punt until we have a use case.
.raise "Prepending abstract mixins is not currently supported."