Stop writing a GameMode per mode.

For one step, yes, and the wiki says so rather than pretending otherwise. SetCurrentExperience takes an FPrimaryAssetId and is server-only, so it is C++ only: your game mode calls it once, after the game state exists. IsExperienceLoaded and GetCurrentExperienceChecked are C++ only too. Everything else is reachable from Blueprint: the experience assets are Blueprint classes, Wait For Experience Ready is a Blueprint async node, and the whole front-end surface (GetAllFrontEndExperiences, GetDefaultFrontEndExperience, GetTravelOptions) is BlueprintCallable.

No. It ships the experience machinery: the assets, the manager component, the policy and the ready signal. You point your own AGameStateBase subclass at UCrimsonExperienceManagerComponent and your own AGameModeBase at an experience id. The Quick Start walks exactly that, and nothing in your inheritance chain changes.

Two things, and only one of them is an ini file. The plugin registers its three primary asset types itself, as soon as the asset manager exists, and marks them AlwaysCook; you only tell it which folders to scan, in Project Settings → Crimson → Crimson Experience → Asset Discovery → Primary Asset Scan Paths. That part matters: an experience is reached through an FPrimaryAssetId, which the cooker does not follow, so an experience outside a scanned folder loads fine in the editor and is simply missing from the package. The Game Features subsystem still has to be pointed at UCrimsonGameFeaturePolicy, and that one does live in Config/DefaultGame.ini. Quick Start step 2 is both, verbatim, and you do not need PrimaryAssetTypesToScan entries any more; leaving old ones in would register each type twice.

Only UCrimsonGameFeatureAction_SplitscreenConfig, which turns splitscreen off for the duration of an experience. Add Inventory, Add Teams, Add Abilities, Add Equipment Slots, Add Crimson Skill Tree, Add Crimson Action Bars and Add Widget are shipped by the plugins that own those systems; they appear in the Actions picker when those plugins are installed. That inversion is the whole design: this plugin never learns what an inventory is.

Because that's the intended order, not a race to win. Actors in a level begin play long before ExecutingActions, so a component, widget or ability grant an action creates does not exist yet. Register a callback instead: from Blueprint, Wait For Experience Ready; from C++, one of the three priority tiers. Code that must not depend on this plugin can wait on the Crimson.Experience.Loaded feature state the manager raises on the GameState, on the server and every client.

None. Crimson is open-core: the foundation and the composition layer are free because they're what gets a project onto Crimson conventions, and the premium gameplay systems are what you buy when you want them. It depends on no other Crimson plugin: just the engine's GameFeatures and ModularGameplay.