The Thor.Action system is built around callbacks, so you're right, thor::ActionContext is indeed the intended way to get access to the original event information. With lambda expressions and std::bind(), it should be possible to use it in a quite compact and concise way.
ActionMap::isActive() is for very simple use cases and does not provide the same level of features as callbacks. Using a procedural approach like this is already quite limited due to its nature. For example, it cannot track whether an event has occured one or multiple times, the boolean return type just allows to query whether it has been fired at least once. In contrast, a callback is invoked exactly once per event.
In order to support such scenarios procedurally, a different paradigma similar to SFML's while (window.pollEvent(event)) would be necessary, but this somehow misses the point of Thor's event-dispatcher abstraction. On the other hand, one might ask why isActive() is still there. And one could be right, it may not fit entirely, but it could help users understand the concept of combining actions and checking if they trigger.
A while ago I considered a design for a slightly higher-level abstraction that would be simpler to use. In particular, it would get rid of boilerplate code such as defining identifiers, and let you directly map from thor::Action to a callback. If you think about it, user-chosen identifiers don't make much sense if they're not queried in a isActive()-style way. In my opinion, such a action->listener map would rather be the way to go for Thor.
