Ashley
I think "fork-and-modify" is not good because of DRY (don't repeat yourself), but do nothing is worse.
Back to the "reuse" topic (or modular), it might have two levels
1. reuse events and related objects for normal c3 users, which could divide project into reuse-able sub-system to improve the work-flow.
2. reuse plugin code for plugin dev, to extend plugin without forking it.
Here I only focus on level 2. "Official sprite plugin and it's related behaviors" is a good example of reusing plugin code, it needs:
1. ability to insert decorator addon (behavior) at another host addon (sprite)
2. a clear interface to define public/export method or callback in host addon for decorator addon, to avoid exposing internal code as your consideration before
For example, a shuffle behavior of an official array could add shuffle function without forking official array. But now, only "world" object could add behavior (point 1).
It could not meet all kinds of requirements if host addon does not provide a clear interface (point 2), for example, it is almost impossible to add "load audio from url" feature in decorator addon for official audio plugin. Therefore addon should be redesign for extending.