I agree that the C++ interface should be better documented. I’m adding the task to my TODO list.
As for having an FSM written in C++, I am really sorry, but that is not going to happen. The main goal of GC FSM is to allow you to write FSMs in blueprints, therefore an FSM is a blueprint function. There’s no concept of FSM class, in fact the class UGCFSM is not meant to be sub-classable. Each state node is implemented with a latent function, so that the blueprint execution can be stopped when the state is entered and resumed when the state is exited. This mechanism is the core of GC FSM. Writing an FSMs in C++ would either require to implement a totally different paradigm or to be able to write coroutines in C++. (This might actually be considered, since VS2017 already supports C++ coroutines in c++17 mode, so at least the PC platform would be covered, However we still have to wait for Unreal to change theirs scripts to allow c++17 builds.)
As for the “Any State” idea, I might consider that. Howerer, please notice that you can already achieve the same result by using a sub-FSM, where the “Cast Spell Failed” event is handled in a higher level of the FSM hierarchy. I’m currently working on a new kind of state node that will make this design approach much easier to implement and maintain. It will be included in the next release.