The issue is not "cookie cutter" feature or "general-purpose", or event-base behavior.
The issue is "how to reduce programming cost":
- "cookie cutter" means users will program with pure events if they need new feature.
- "general-purpose" means users might add some or a lot of events to match their requirement.
( Some time they will never get it, so they will ask pure event-base behavior, I do not agree official plugins are "general-purpose" already, since users still could not reach their targets. )
- "pure event-base behavior" means a lots of events.
The better solution will reduce events in all cases.
A possible solution is start at pure event-base behavior-- "how does users modify it for new features?" Then breaking it into plugins(behaviors). Finally it will be a plugins-system which left some hooks for users to add new feature by events or by plugins-- It is not a single plugin or behavior, it is a reuse-able architecture.
Do not trapped by "single plugin/behavior", this kind of solution does not have enough flexible. Sprite(plugin) could have behaviors like extending slots/decorators, how about behaviors' extending slots/decorators?