IMHO there should be no DoubleJumpSystem, but there should be no JumpSystem either. Going this way will make things needless complex. Instead, an integrated solution should be data driven, perhaps like so:

OS / input device originating raw input is fetched from the InputSystem and translated into engine encoded input (we neglect the nitty-gritty details about this topic here). The ControllerComponent instance of the PC recognizes input that denotes "jump", or the AI of the NPC decides to "jump". This abstract command is passed to the state machine of the PC/NPC. The current state defines whether or not jumping is possible, e.g. the current state must provide an outgoing transition which can be triggered by the "jump" command and has no suppressing conditions active. (Well, an AI will usually not ask for a "jump" if it is not possible, but for the sake of simplicity we do so.) The state referring to is the "now jumping" state. The state machine is either part of the animation system, or else the animation system is controlled by the state machine, and hence plays black the animation belonging to "jump" just because the new current state is "jumping".

This way differs from having a sub-system for each movement in not grouping the movements by kind over all characters, but the movement abilities for each particular character into a state machine. The state machine can be instantiated from a template for equal characters with equal movement abilities, of course.

A animation system should be able to run animations on any animated object, being it the PC, an NPC, an item, or whatever. How the object can be animated at all is a question of data (e.g. tracks of key frames bound to positions and orientations). How animations are actually run is a question of controlling variables, which in turn are controlled by the state machine and CharacterController or AI, resp.

Thanks for the descriptive answers guys! I think I got it now.