Dynamic animation retargeting

Hello,

while working on Spriter support for Unity, i've encountered some major problems. One of them was that the animations created via [Create new clip] have sprites assigned to them, which makes problems like "changing part of the character" or "changing whole character" unsolvable, unless a whole new animation is created for them.

To tackle this problem i prepared a system that uses animation events and knowledge about all required sprites, however it's kinda hacky and i'd be much better to solve it in a cleaner way.

First of all - what is the target (watermark to protect brashmonkey guys stuff)
https://dl.dropboxusercontent.com/u/5885835/TestCharacterMaps_osx.zip
https://dl.dropboxusercontent.com/u/5885835/TestCharacterMaps_win.zip

As you can see from the example, animations are sprite independent but still sprites are changed (blinks and facial expressions are the best examples)

How it's done now:
- root node contains a script that have all the required sprites assigned (as well as names, paths and SpriteRenderers for faster changes)
- all animations are triggering animation events, with a properly prepared string, each time a sprite change is required
- magical string consists of name of the animation and index of the sprite that should be replaced
- during transitions, only events from the "next" animation state are accepted (as events from both animations are received) (there is no obvious way to obtain information about caller of the function nor animation that triggered the event, i have to keep animation name within the magical string)

What are the problems:
- due to limitations, only one animation layer is checked for transitions (as i don't really know from which layer an event is sent nor i know on which layer all animations are placed)
- parsing string and doing all those checks could have negative impact on performance with multitudes of sprites at once (as this is only the animation, this should have as little impact as possible)

TL;DR

What would be the nice solution:
1) Cleanest of all on my side, but could be dirty for Unity code architects: SpriteRenderer would hold a list of sprites, show only one of them at a time and the index of the sprite shown could be changed via "Add Curve"
2) Rather clean for everyone: allowing MonoBehaviour variables to be modified via "Add Curve", the same way e.g. transform.position is changed or even the same way UnityEngine.Object.Enable is changed.

What would it change:
- all the problems for current implementation are no more