Bind input by tag, not by pointer.

Both halves of that are true, so here is the split. Blueprint gets the config and its three Find…InputActionForTag lookups, native input through the standard Enhanced Input Action events, chords, per-player rebinding and conflict checks, key profiles, the key + chord display node, the modifiers and the sensitivity data asset. C++ is needed for three things: the bulk binders BindNativeAction / BindAbilityActions (they are templates), a true release edge on ability input (GAS exposes no Blueprint release-by-tag, so you route Completed and Canceled into a small BlueprintCallable forwarder of your own), and CommonUI action binding, because Unreal ships no Blueprint node for FBindUIActionArgs(UInputAction*, …).

No. CrimsonInput builds and runs on its own with only engine plugins, and it does not depend on CrimsonAbilitySystem: GAS binding uses the engine's IAbilitySystemInterface. CrimsonCore, the free integration layer from the Crimson Discord, joins it to the rest of the suite: chord glyphs in CrimsonUI, combo modifier tags in CrimsonAbilitySystem, chord-aware key text in CrimsonActionBar, and chord capture in the CrimsonSettings screen. Without Core, call the same public API (UCrimsonInputDisplayStatics, ICrimsonInputBindingProvider) from your own code.

Yes. CrimsonInput is free, Input Clash Analyzer included.

Yes, without ever naming your ability system. BindAbilityActions bulk-binds the config's ability list and hands your callback the action's FGameplayTag; you forward it to whatever ASC your pawn or player state exposes, resolved through the engine's IAbilitySystemInterface. Grant the ability with the same input tag on its spec (and on its Asset Tags if you take the Blueprint Try Activate Abilities By Tag route) and the two meet. For a combo-capable character, BindAbilityActionsWithAction passes the UInputAction* alongside the tag, so a combo router can identify the press and fall through when it does not consume it.

Yes. Set an action's Player Mappable Key Settings class to CrimsonPlayerMappableKeySettings and give it a Name; per-player chord overrides persist under that name through UCrimsonInputUserSettings, which is a UEnhancedInputUserSettings subclass, so ordinary Enhanced Input key rebinding comes along with it. FindChordConflict warns before two actions land on the same key with the same chord, gamepad input bypasses chord checks entirely, and chords are exact-match: an action requiring no modifiers is blocked while any modifier is held. One gotcha the docs are blunt about: Enable User Settings and User Settings Class must both be set under Project Settings → Engine → Enhanced Input, or GetUserSettings() returns null and chord persistence silently does nothing.

No. Bindings, chords, modifiers and the config are evaluated on the owning client only; none of it is replicated gameplay state. Authority arrives one step later, through the ability the input activates: the server authorizes activation, and the docs are explicit that you should never drive an authoritative change straight from an input callback.