Personally I don't really care for aliasing, my only real concern is preventing this:

    $Table->addBehavior('NeedEventHandler');
    Fatal Error
    Exception NeedEventHandlerBehavior contains duplicate method whocaresImnotgoingtoevencallthat which is already provided by UsingOtherStuffBehavior

I don't expect method aliasing to get much use _except_ to circumvent the above and expose a behavior method via a different name. If aliasing is the main problem, I can simply remove it.

So crunch points, as of 3.0's current code:

 * Adding a behavior which implements a method already provided by another behavior throws an exception
 * The above should be user-solvable without "oh well, I can't use those two behaviors together" or worse copy/pasting the behavior somewhere else and deleting/renaming the duplicate method.
 * In the event of a behavior name conflict, in 2.x the user could simply do  `$Model->Behaviors->BehaviorName->inaccessbile($Model')` or equivalent, in 3.x they are SOL.
 * With finders being chainable, there are likely to be a lot more methods defined in behaviors in the future (ala: `$Table->find('all')->active()->recent()->by('bob');`)
 * Adding a behavior which implements a method already provided by the table does not throw an exception.
 * `Table->foo()` being rewritten to `Table->find('foo')` automatically will likely lead to ambiguity or at the very least the risk that adding a behavior that does nothing (except implement `public function foo`) killing all queries calling `Table->foo()`
 * A behavior aught to be able to disable/remove a method (e.g. tree behavior, adjacent list mode -> no moveUp/moveDown methods)
 * It's possible to implement a method on a behavior and effectively override the table's own implementation - i.e. findAll, findList and findThreaded (which incidentally I think should move to the tree behavior) - that's not going to be expected.

Phew! Where do we want to go?